Skip to content
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

Added read_only role #1217

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from
Open

Added read_only role #1217

wants to merge 11 commits into from

Conversation

umair-nasir14
Copy link
Collaborator

The read_only role can only see the response list. For now, it can also assign reviewers.

@umair-nasir14 umair-nasir14 requested a review from avishkar58 May 23, 2024 06:38
Copy link
Contributor

@avishkar58 avishkar58 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Muhammad, Thanks for the PR!
I have a question on the overall design - I think it makes total sense to have an event role for "read_only" which gives read-only access to a particular event, which you have. But what I'm not sure about is the reason for adding a global is_read_only flag like how we have the global is_admin - I can't think of a use-case that would require global read-only access - is there one for AIMS perhaps that I'm missing?
Thanks!

@umair-nasir14
Copy link
Collaborator Author

Hi Avishkar!

Thanks for the review!

So from my understanding, AIMS have many directors who require read-only access while viewing application responses. I thought it would be fine to have a global flag which can cover all the use cases. Don't know if this makes sense.

Thanks again!

@avishkar58
Copy link
Contributor

Thanks for the explanation! So we generally try to avoid adding global flags to the users, because this is something that affects the entire system for all organisations and globals have a way of polluting the codebase. You'll notice that in the user model we have a lot of fields that are no longer used because those globals which we introduced initially reduced the flexibility of the system and so we had to deprecate them. In this case I don't think the motivation to add a "read-only" global is strong enough, so lets please remove that and stick to the event role.

Then for the event role, I think it would be better to make the role more fine-grained. From what I understand, the requirement here is to give read-only access to the responses, so lets make the role exactly that: "response-reader". I see in your description that the current "read_only" role also gives the ability to assign reviewers, which is a write action and therefore very confusing. Lets introduce another role for that, "review-manager" or something like that. We can add as many event roles as we like, so I'd prefer to keep those more fine-grained and intuitive as to what they mean. (For now, imagine an admin who isn't familiar with the code, seeing this event role "read-only", I think in its current state the admin would not be expecting it to do what it currently does.)

@umair-nasir14
Copy link
Collaborator Author

Thanks for the detailed review.

Understood, makes perfect sense! I will get back to you when it is done.

@umair-nasir14 umair-nasir14 requested a review from avishkar58 June 12, 2024 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants