Bug #16683
Updated by Peter Amstutz over 4 years ago
h2. Workbench 1 h3. Share with group Steps to reproduce: # Create a LoginCluster federation with 2 instances # Go to the 2nd instance and log in with a non-admin federated user # Create a project # Go to the sharing tab # Share with "all users" On reloading the sharing tab, it'll get fiddlesticks: request failed: https://172.17.0.3:8000/arvados/v1/users?cluster_id=&count=&filters=%5B%5B%22uuid%22%2C%22in%22%2C%5B%22x1ly6-j7d0g-fffffffffffffff%22%5D%5D%5D&limit=9223372036854775807&offset=0: 400 Bad Request: cannot execute federated list query unless count=="none" [API: 400] h2. Workbench 2 h3. Sharing dialog Fails to open with the similar error: request failed: https://172.17.0.3:8000/arvados/v1/users?cluster_id=&count=&filters=%5B%5B%22uuid%22%2C%22in%22%2C%5B%22x1ly6-j7d0g-fffffffffffffff%22%5D%5D%5D&offset=0: 400 Bad Request: cannot execute federated list query unless count=="none" Also observed: attempting to share with a user gets a "unknown uuid" error. This is probably due to the fact that although the user can see other users from the login cluster, the permissions are checked on the federated cluster, which doesn't know that. The validity check on the link tail for permission links should probably just suppress raising an error when the cluster id isn't the local one. (alternately, we could skip the check entirely, this would partially address the previously reported problem of curators being unable to share with groups that they don't have access to, although they would need to add the permission link by uuid, possibly via the command line, which might not be acceptable.)