Units as Objects and Permission Inheritance Changes

[joncameron]

Description

Management of collections in large Avalon instances would be better served by Units being full objects with permissions attached. These permissions could then be inherited by collections for management and access control purposes. A unit is a grouping of collections for administrative and discovery purposes

It should also be easy to add, remove or change the name of a Unit.

Primary Changes

• A new Unit object is added
• Each Collection is the child of a parent Unit
• Staff and user permissions set at the Unit level also apply to child Collections and their objects
• Inherited permissions are able be revoked on media objects
• The Manager system group is retired, and the ability to create collections and be assigned a Manager role comes from the new Unit Administrator role

Permission Inheritance

Inheritance is already at work in Avalon via staff roles. Users in staff role for a collection receive permissions based on their role, and that applies to all objects within a collection.

Diagram of Inheritance

Use case

• A collection manager with many collections wants to manage access by their administrative department or unit

For example, a new staff member joins an area. Currently, a department with 12 collections would need to add that username individually to each collection.

Current pain points

• Adding or removing Units requires editing a yaml file
• For units with many collections, adding and removing collection staff is a manual and tedious process

DRY

Changing the inheritance model would mean 1 object changes, instead of 1000 children objects change. In an application like Avalon where object updates are costly, this is both tedious and redundant. Granting access, then revoking access for many items is painful.

Changes

New Object: Units - #6054

• Each Unit will be an object with NOID
• Collections become child objects of Units
• Attributes include name, description etc; full listing in

Views

Manage Content View

• Move "Manage Content" from /admin/collections to /admin

New Views for Units

• Unit landing page
  • ex: https://avalon.site/unit/12579s27f
• Unit admin page
  • ex: https://avalon.site/admin/unit/12579s27f

Updates to Collection Views

• Collection Show View
• Collections Show View - Link to Unit on View Collections Page #6056

Permission Scheme Changes

• Units have a new staff role, "Unit Administrator". Only Unit Administrators are able to add users to the Manager group for any collection within the unit. Unit Administrators are able to add users to any staff role for a unit. Multiple values are accepted to this field, in the way that is already used for Managers, Depositors etc. This new role removes the need for the Managers group.

• Only Administrators are able to add users as Unit Administrators.

• Only Unit Administrators are allowed to edit Unit metadata and to add new users to the Manager role

• Managers can add users to staff roles for any collection

Permission Inheritance

• Special access settings inherit from parent collection - Items Inherit Unit- and Collection-level Special Access Settings #6059
• Staff roles inherit from parent collection Items Inherit Unit- and Collection-level Staff and Special Access Roles #6060
  • can be assumed from collection (no special handling for these?)
• Items can have permissions inheritance revoked (for very sensitive or restricted items)

[elynema]

Units can have contact email, website URL, just like Collections. What about poster images? For inheritance, every collection in the unit has the same permissions as the unit, can add users but not remove them. Same with inheritance down to the item - can add users but not remove them.

First thing to test is inheriting Special Access down to the item level.
When changing Item Access for the unit or collection, need a list of items where Item Access was set at the item level to determine whether those items should remain custom or be updated to match the new default for the unit or collection. This could possibly be accomplished through a link to the Blacklight results page for the collection with the Item Access facet expanded. If change Item Access for the Collection, should probably also include a notification to the user of "[x] number of items will be updated" with the number of items that will have Item Access updated.

Under Item Access at the item level, there should be an indication of the collection default so that collection owner can see if they are changing a setting to be different from the collection default.

Propose that we start with just the Special Access and Staff Roles at the Unit level. There is not a strong use case for have Item Access at the Unit level and making changes there. Also retain CDL at the Collection level; don't move to Unit.

Tickets:

• make Unit a first order object w/metadata, including poster image (Add Unit Objects #6054)
• On View Collections Page, the unit name should link through to the unit (Link to Unit on View Collections Page #6056)
• set Staff Roles at unit that are inherited by collection (Collections Inherit Staff Roles from Unit #6057)
• set Special Access at unit that is inherited by collection (Collections Inherit Special Access Permissions from Unit #6156)
• Inherit Staff Roles and Special Access from unit/collection at the item level (instead of storing them all at the item level); includes display of default value for Special Access from collection and allows adding more at the item level (Items Inherit Unit- and Collection-level Staff and Special Access Roles #6060)
• Staff Roles and Special Access when displayed at the collection level should show unit default values and allow selection of a different value at the collection level (covered in Collections Inherit Staff Roles from Unit #6057 and Collections Inherit Special Access Permissions from Unit #6156)
• No longer need to provide option to apply collection level Special Access changes to items. We assume that a chance in either Staff Roles or Special Access should trickle down to item. (Remove "Apply to All Existing" Special Access Action #6157)
• Migration of existing permissions data (Migration of Existing Permissions Data #6063)
• Explore removal of the manager group (any user who is manager of a unit should be able to create collections in that unit) (Remove "manager" System Group #6158)
• Do we need a Unit Manager role or group instead to define the person who can add managers to a unit?
• Create collection button on the Unit page or the Manage Content page. Drop-down from the Unit page shoud bring up create collection form with current unit drop-down pre-populated. Drop-down should only include units you have permission to create collections within.
• Define permissions for each unit level staff role