Permissions Management - Explore derived roles implementation

[deepaksftc]

Now that the dynamic role creation feature has been merged and the tagging framework is in place, we need to validate the existing capabilities and evaluate them against the use cases that permissions implementations are intended to address. This will help us identify and document which use cases still require a dedicated permissions solution.

[Scott-James-Hurley]

Notes

• Will need to add backend validation
• Filtering elements should handle things for the most part
• Hardcoding will remain
• Permission checks will become more complicated with addition of tag logic
• Filters need to reflect options user can use
• Need to be able to filter things such as workflows
• The proposals and assignments page should be fine - only shows proposals currently in a fap status

Questions:

• How would viewing faps work - they can span multiple instruments and users need to be able to see fap meetings they were a part of, that others that have joined since should not be able to see
• Will tags be checked when exporting stuff - affecting the output
• How would we handle settings for different facilities?
• Would things like questions and templates need tags as well - would need to extend what can have tags attached to them

[deepaksftc]

Did a quick check through the open and closed issues which had some reference to the need for roles and permissions.

Permissions scenario.txt

[deepaksftc]

After the initial analysis, we had a meeting with UO, EG to go through all the backlog issues and UO requirements for future. Seems most of UO’s requirements are now largely addressed by the derived roles and tags. EG is happy to pause the implementation of permissions for now and try of how the implementation of derived roles and tags work out.