Configure Admin Access Controls

[jgladwig]

While basic access controls currently appear to work as intended for non-admin users there are some improvements to be made. For basic users any protocol created is assigned that user as owner and any time a user requests a list of protocols they receive all of the protocols that are marked with that user as owner.

This intended behavior currently breaks down for admin users and admins receive the protocols for every user. This is likely due to some configuration flaw with our use of django-oso. Admins by default appear to have access to all protocols regardless of owner field. While this kind of behavior could one day be considered as an option for admins... right now the frontend is not built to handle receiving all protocols for all users.

The incremental step forward here would be to ensure admins only receive the protocols for which they are specifically listed as owners.

[danbryce]

I’m not sure what is needed for this right now, but I’d leave it for them to have access to everything without separating out by user.

…

On Feb 9, 2022, at 1:18 PM, jgladwig ***@***.***> wrote: While basic access controls currently appear to work as intended for non-admin users there are some improvements to be made. For basic users any protocol created is assigned that user as owner and any time a user requests a list of protocols they receive all of the protocols that are marked with that user as owner. This intended behavior currently breaks down for admin users and admins receive the protocols for every user. This is likely due to some configuration flaw with our use of django-oso. Admins by default appear to have access to all protocols regardless of owner field. While this kind of behavior could one day be considered as an option for admins... right now the frontend is not built to handle receiving all protocols for all users. The incremental step forward here would be to ensure admins only receive the protocols for which they are specifically listed as owners. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[jgladwig]

The main issue on the frontend is that it makes some assumptions that protocols have unique names. That assumption is enforced and holds true within each user's scope but that does not hold true across multiple users (User A and User B can both have a protocol named 'example'). So when an admin user sees multiple protocols of the same name it will have a key clash and display incorrectly.

Removing that assumption from the frontend and instead keying off of something that in globally unique (the protocol id) may be a fine answer.

[danbryce]

I think that using id in the frontend is a fine idea, and should be a small change.

…

On Feb 9, 2022, at 5:03 PM, jgladwig ***@***.***> wrote: The main issue on the frontend is that it makes some assumptions that protocols have unique names. That assumption is enforced and holds true within each user's scope but that does not hold true across multiple users (User A and User B can both have a protocol named 'example'). So when an admin user sees multiple protocols of the same name it will have a key clash and display incorrectly. Removing that assumption from the frontend and instead keying off of something that in globally unique (the protocol id) may be a fine answer. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.