Use Cases
Use Case | |
---|---|
New admin account created with a sandbox in which studies can be created/edited that are not visible to others | |
“Sandbox” can be converted to real study, with additional users in specific roles for that study | |
Study is extended by creating a new study | |
Study recruits from existing user pool into a new study | |
Add someone to a study’s administration team | |
Remove someone from a study’s administration team | |
Create similar authorization model for assessments | We should be able to expand it to other things than studies, because it seems likely we’ll encounter something else that needs finer-grained authorization. |
Assuming a generic authorization model (user → has permission → object), maybe we don’t need groups. But we should look at other systems to see what it buys us. I think that practically, it’s difficult to grant read permissions to a group without a grouping construct (I create a new study and the system has to figure out who should be able to see it…that’s not easy with overlapping associations).
Implementation Considerations
We’re reimplementing a lot of the functionality of Spring Security’s authorization support. It might be desirable to switch over rather than further implementing a custom solution.