Units in Avalon

[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—actions which currently require a configuration file to edited.

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.

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.

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.

Unit Objects

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

New Views for Units

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

Mockups

Unit Admin Page

### Collection Admin Page

[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 Unit Staff Roles #6057)
• set Special Access at unit that is inherited by collection (Collections Inherit Special Access Permissions #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 Unit Staff Roles #6057 and Collections Inherit Special Access Permissions #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