Conversation
…re into poc_dynamic_role_creation
…ect/user-office-core into poc_dynamic_role_creation
…re into poc_dynamic_role_creation
…re into poc_dynamic_role_creation
2 tasks
added 2 commits
February 5, 2026 13:37
…s for permission checks fix: add comments to clarify exception handling in getProposalsFromView
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
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.