Idea #15720
Updated by Peter Amstutz about 5 years ago
When choosing to share a project with another user, the contents of the dialog box is populated from the user database of the local cluster. Non-local users only appear if they have previously accessed that cluster in some way (causing a user record to be created). This means when attempting to share a project with another user, that user may or may not appear in the list based on whether the user has ever accessed that cluster in the past. (It is also invalid to create a sharing involving a user uuid that doesn't appear in the users table). This is confusing. For the case where LoginCluster is set, this can be solved by having arvados controller proxy user record listing requests to the LoginCluster. The API server also needs to allow permission links that point to users uuids that are not already cached in the users table -- possibly by automatically creating a stub record for those users. For the general case, controller would need to query the user listings of all known remote clusters and merge them into a single response. (we could probably defer this) Kind of related: what happens when a user merges accounts on the main cluster? All the other clusters should be synchronized and merge the old user to the new user. Should the API server merge account feature do this? h2. Agreed Proposed solution for the LoginCluster case: * When LoginCluster is set, Controller proxies requests to "get" get or "list" list user records to the LoginCluster. Controller uses the response from the LoginCluster to create or update user User records in the local database are updated from the response before returning the response to the client. If the query contains 'select' only update the fields in the response (must include 'uuid').