Thoughts on this...

1. Would you want the workspace owner to allocate Airlock manager and other owners (only the workspace researcher is specified above)?
2. Is a config setting good enough to disable the APIs and UI User Management elements?
3. If User Management is disabled, do we still want to allow the viewing of assigned users to a workspace or should we just hide the tab?

From our perspective, we do not want Workspace Admins or Researchers to be able to allocate people to roles in their workspaces.

Having them add new researchers who haven't been vetted is a violation of the Safe People principle. Allowing them to allocate Airlock Managers would invalidate the entire concept of the TRE, since they'd be marking their own homework.

The only potentially useful functions for our environment would be:

1. Allowing Workspace Admins to shuffle their existing users between the roles of Researcher and Admin. Useful when a Researcher needs more access, or when an Admin is leaving a running project.
2. Allowing Workspace Admins to remove someone from the project entirely, but not to then add them, or anyone else, back in.

Anything else would be bad news for us, so please make sure that any such features are configurable, so we can disable them.

@fortunkam keep it to TRE Admins for now, we will need to revisit RBAC across the TRE at some point as use cases are getting more complex. #3826

Config setting for API and UI sounds like a good idea. We are also likely to do one for cost reporting as per #4318

If can hide the whole user section, as we can get more granular using RBAC down the line.

Thank you!

This is the current WIP.

Will make sure the assign/de-assign is only available to TRE admins and only if the flag is set.

This is the current WIP.

Will make sure the assign/de-assign is only available to TRE admins and only if the flag is set.

Excellent.