Decouple user email from role name #18966
Conversation
jdavcs
added
kind/enhancement
area/API
area/admin
area/database
jdavcs
force-pushed
the
dev_private_roles2
branch
2 times, most recently
from
4e35f14 to
84a30a2
Compare
jdavcs
force-pushed
the
dev_private_roles2
branch
8 times, most recently
from
5f1502a to
d06cf20
Compare
jdavcs
changed the title
Now that role name doesn't have to be unique, we don't want to pass args like "private role" or "shared role" on role creation.
Because we no longer can match role name to user email
Reason: decouple user email from private role naming: emails can be
changed or redacted; user id in user-role-association + role type is
sufficient to tie a user to a private role.
The description (i.e., "this is a private role for a user" is inferrable
from the role name ("private role"), which is assigned by default.
We must use a union because when we retrieve roles with a query, we check against: 1) role name 2) email of associated user for private roles We factor out this select into a helper method, which we then test extensively.
jdavcs
force-pushed
the
dev_private_roles2
branch
from
d06cf20 to
16f1d3f
Compare
|
This is ready for review. |
Co-authored-by: David López <[email protected]>
Co-authored-by: David López <[email protected]>
not sure I understand this, I presume that's something we used to have a user interface for ? does that need to be added back ? |
Co-authored-by: Marius van den Beek <[email protected]>
Co-authored-by: Marius van den Beek <[email protected]>
Sorry, this is confusing out of context! It's for the populator - see my previous response, I think it covers it. |
|
Thanks @jdavcs! |
|
This needed a migration rebase prior to merge, we have two heads now @jdavcs |
|
Sorry! A new migration sneaked in. I'll handle this. |
The idea is to decouple emails from role names. In this approach, we remove the unique constraint from the
role.namefield in the database, which allows the creation of generic roles like "private role" or "sharing role", which do not depend on a user's email and are identified by their type and a relationship stored in the user_role_association table. However, when an admin user manually creates a role in the admin UI, they will be required to pick a unique role name. Otherwise, an admin may accidentally create duplicate roles with names that are intended to distinguish them from other roles (e.g. we don't want multiple role names like "Foo lab").Notes:
This adds a new API endpoint for retrieving user roles (currently used to retrieve a user's private role, which is no longer possible by retrieving all roles and selecting the one with the name matching the user's email).
How to test the changes?
(Select all options that apply)
License