Comments on Understanding Admin Sets Participants

admin_set_participants_feedback.md

Here are the divergences I found with https://github.com/projecthydra/sufia/wiki/Understanding-Admin-Sets-Participants

Admin Set Managers

1. Admin Set managers can not currently edit Admin Set metadata until they are elevated to repository administrators. This is because only repository administrators can access the Admin Set edit UI, which is under /admin/. When an Admin Set manager deposits to an Admin Set, they have edit access.
2. Admin Set managers can not edit works simply by virtue of being Admin Set managers; this is controlled by the work's ACLs still.

These two are yet-to-be-implemented features.

Admin Set Depositors

3. Admin Set depositors can only edit works in an Admin Set if they have deposited the works themselves.

I think this is as we want it to be.

Admin Set Viewers

4. Admin Set viewers can not view works simply by virtue of being Admin Set viewers.

This is a yet-to-be-implemented feature.

1. Fix in Hyrax (2.0) MVP; hide in Sufia master
2. Fix in Hyrax (2.0) MVP; hide in Sufia master
3. Punt Admin Set Viewers impl post-MVP; write up in Hyrax 2.0

1. Question: Is the plan to change the admin_set controller and views (the ones not under the admin directory) to include an edit form? For non-admin manager users, they will be able to edit from there? Admins would be able to edit from there or the Administration menu?
2. Agree. I am assuming that the reason for giving managers edit_access to new works created in the Admin Set is to allow ACLs to control access after creation. Being a manager gives you no special privileges for works beyond setting edit_access when the work is created.
3. Agree. Isn't this the case now?
4. Agree. Again, my understanding is that the only impact of being a viewer is that they are given read_access for new works created in the Admin Set. After that, ACLs control all access to the works.

Side note about admins and administration menu:
I have always envisioned the admin menu to be more role driven. Many users have some admin functionality we want them to be able to do.

Examples:

• As a super_admin, I want to be able to check message queues.

• As a super_admin, I want to be able to block a user from using the site.

• As a super_admin, I want to enable workflows.

• As an admin, I want to be able to see all users.

• As an admin, I want to be able to add users.

• As an admin, I want to be able to see site wide stats.

• As an admin, I want to be able to create Admin Sets.

• As an admin, I want to be able to set Managers for Admin Sets.

• As a manager, I want to be able to edit admin sets that I manage.

• As a manager, I want to be able to assign users as participants in an admin set that I manage.

What abilities go with what level of administration may be site dependent. Having a super_admin and an admin allows for some trusted users to have more power with out having to give them all power.

I bring this up, because I do not see it as inconsistent for an Admin Set manager to have an Administration menu with Admin Sets as an item in the admin left side menu. When they go to it, they see the Admin Sets they manage. There will not be a Create Admin Set button because as a manager, they don't have the ability to create Admin Sets.

Going this route will make the UI/controller changes allowing managers to edit Admin Sets easier.

In reply to your latter comment... I envision the administrative menu the same way, Lynette, and there's a PR in Hyrax now to merge the user and admin dashboard as a move in this direction.

In reply to your former comment...

1. Building on the other comments, the plan in Hyrax is to leverage the combined user/admin dashboard and grant Admin Set Managers access to manage admin sets in this UI. Inclination is to work on this in Hyrax since I don't think this feature is in scope for 7.3.0 (now that we're in the release candidate phase).
2. My take here is that an Admin Set Manager should have the ability to edit all works in an Admin Set, and I'm ambivalent regarding whether we implemented that in persisted ACLs or Ability logic. Inclination is to work on this in Hyrax since I don't think this feature is in scope for 7.3.0 (now that we're in the release candidate phase).
3. Yes, this is the case now.
4. It sounds like we're on the same page here. Inclination is to work on this in Hyrax since I don't think this feature is in scope for 7.3.0 (now that we're in the release candidate phase).

Tickets written up:

• samvera/hyrax#563
• samvera/hyrax#564
• samvera/hyrax#565