lsitu
commented
7 years ago The implementation for access control in Plum is role base, which has the following roles: admin - with full permissions (default in hydra) image_editor - with permissions to read, create, update works, and update files etc. editor - with permission to read existing works, update public works, update files, and flag public and private works for review etc. fulfiller - with permission to read existing works, update public works, and flag works for review etc. curator - with permission to read existing works, update public works etc. campus_patron - a user who logged in plum, who has permissions to read public and institutional visibility works. anonymous - a public user, who has permissions to read public works only.
The workflow state gated discovery strategic is implemented basing on the default blacklight gated discovery, and the private works (own by personal) may not be exposed any roles other that admin.
I think the main different with the roles base access control in dams4 is the campus access, which is controlled by IPs but not depends on whether a user is logged in or not, and all objects (including those private ). Since workflow will be implemented as a standard component in hydra (see ticket https://github.com/ucsdlib/dams5-cc-pilot/issues/48), I'll create a PR to implement the roles base access control for the Sufia base pilot project horton, which has the following roles for now: admin - with full permissions. editor - with permissions to read, create, update, destroy objects and collections (public, ucsd, private). curator - with permissions to read objects and collections (public, ucsd, private). campus - with permissions to read public and ucsd objects and collections. anonymous - read public objects and collections only.
Gated discovery strategic will be implemented to override the default blacklight gated discovery to expose all objects and collections (public, ucsd, private) to admin, editor, and curator roles.
Following a discussion with Mike Giarlo, he referred me to the group access model that Plum has built and noted that it might be a good fit for Sufia.
Please research how this is built and how it compares to our local assumptions about curator/edit groups and ownership.
If it sufficiently aligns, please consider the level of effort necessary to bring this support into Sufia. Feel free to contact Mike either via hydra-tech, hydra slack #dev channel, etc. if we get to this point.