-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Decoupling user email from role name #18966
Draft
jdavcs
wants to merge
22
commits into
galaxyproject:dev
Choose a base branch
from
jdavcs:dev_private_roles2
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jdavcs
added
kind/enhancement
area/API
area/admin
area/database
Galaxy's database or data access layer
labels
Oct 9, 2024
jdavcs
force-pushed
the
dev_private_roles2
branch
2 times, most recently
from
October 10, 2024 20:24
4e35f14
to
84a30a2
Compare
jdavcs
force-pushed
the
dev_private_roles2
branch
2 times, most recently
from
October 23, 2024 20:03
cd0b567
to
9a60351
Compare
Because we no longer can match role name to user email
jdavcs
force-pushed
the
dev_private_roles2
branch
2 times, most recently
from
October 25, 2024 21:26
bedbc04
to
7c8fe41
Compare
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.
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.
Reasons: not needed, query is ambiguos after decoupling user emails from role names
- Add user email to represent user's private role - Exclude generic role names
jdavcs
force-pushed
the
dev_private_roles2
branch
from
October 25, 2024 22:00
7c8fe41
to
b5b8689
Compare
jdavcs
force-pushed
the
dev_private_roles2
branch
from
October 25, 2024 22:12
b5b8689
to
9929a46
Compare
jdavcs
force-pushed
the
dev_private_roles2
branch
from
October 25, 2024 22:55
9929a46
to
75b298d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft.
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).
The idea is to decouple emails from role names. In this approach, we remove the unique constraint from the
role.name
field 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").TODO:
How to test the changes?
(Select all options that apply)
License