elynema
commented
2 months ago 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
- On View Collections Page, the unit name should link through to the unit
- set Staff Roles at unit that are inherited by collection
- set Special Access at unit that is inherited by collection
- 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
- 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
- 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.
- Migration of existing permissions data
- Explore removal of the manager group (any user who is manager of a unit should be able to create collections in that unit)
- 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
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.
It should also be easy to add, remove or change the name of a Unit—things which are not currently very intuitive.
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
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.
A New Object
New Views for Units
Mockups
Unit Admin Page
Collection Admin Page