feat: introductin root_role and derived_role (based on tags)#1282
feat: introductin root_role and derived_role (based on tags)#1282
Conversation
…re into poc_dynamic_role_creation
apps/backend/db_patches/db_seeds/0002_InstrumentScientiests.sql
Outdated
Show resolved
Hide resolved
…ect/user-office-core into poc_dynamic_role_creation
…re into poc_dynamic_role_creation
…re into poc_dynamic_role_creation
jekabs-karklins
changed the title
|
Hello @mutambaraf, After a couple of false positives, I got the PR to pass the end‑to‑end tests. This PR introduces the proposal_reader role. It lets a tagged user view all proposals for the tagged instruments or calls—same access as a User Officer, but without permission to modify anything |
mutambaraf
left a comment
mutambaraf
left a comment
There was a problem hiding this comment.
Just this one comment still trying to get it to work on my dev.
| DO | ||
| $$ | ||
| BEGIN | ||
| IF register_patch('Add tags to role and set variable for default roles', 'Fredrik Bolmsten', 'tag_to_role', '2025-12-09') THEN |
There was a problem hiding this comment.
We may need to update this date its now to far in the past.
mutambaraf
left a comment
mutambaraf
left a comment
There was a problem hiding this comment.
Looks good l have added some few comments
| }; | ||
|
|
||
| export default context; | ||
|
|
There was a problem hiding this comment.
Do we also need this comment
| if (!featureFlags.getEnabledFeatures().get(FeatureId.TAGS)) { | ||
| if ( | ||
| !featureFlags.getEnabledFeatures().get(FeatureId.TAGS) || | ||
| !featureFlags.getEnabledFeatures().get(FeatureId.OAUTH) // TODO implement method setUserRoles in StfcUserDataSource and remove this condition |
There was a problem hiding this comment.
I have opened this issue to remove this comment.
| : api({ | ||
| toastSuccessMessage: 'Role created successfully', | ||
| }).createRole({ | ||
| args: { | ||
| shortCode, | ||
| title, | ||
| description, | ||
| permissions, | ||
| }, |
There was a problem hiding this comment.
We have not implemented this but l am getting a success message when l try to create a role we may need to find a way to wait because the backend looks okay.
| const role = (await context.mutations.user.createRole( | ||
| context.user, | ||
| args | ||
| )) as Role | Error; | ||
| if (role instanceof Error) { |
There was a problem hiding this comment.
It may be nice to also log the error.
3 participants
Description
My proposal is to continue using pre-defined roles (now called root roles) and dashboards, but allow for the creation of dervied roles that has two attributes: “data access” and “permissions/config”. The derived roles link to the root roles and inherits the dashboard and the permissions of the root role. This means that much of the code can stay the same.
For example: I added a new root role with associated dashboard and created two derived roles ISIS_READ and CLF_READ—both using from the root role proposal_reader role. The only difference between the dervied roles is the data access tags. That would allow users to login and see a proposal table with only the proposals that has the instrument associated with their data access tag.
We can do minor configurations for each dashboard using a permission/config defined on the derived role and we can set the data access either by using tags.
It would also allow for different facilities to rename roles like FAP Reviewer to PEP Reviewer.
A derived role has the same functionality like the root role until tagged and then the data access is determined by the tag.