Overview

A key component of the chartered work for the Repository Management Functional Requirements Group (FRG) was to address permission needs for repository activities and entities:

Create matrix of entities, roles, activities and user stories to articulate Management activities and permissions:

Identify management activities performed on repository entities (objects, collections, files, policies, agreements, etc.: creating, editing, deleting, triggering preservation actions)

Determine staff needs around managing versions of content (e.g. metadata versioning; file versioning; whole object versioning; object restoration)

Outline needs for users/permissions management within a management application (users, groups, roles, etc.)

Identify access controls and roles needed to support deposit and approvals

Determine requirements for access controls for discovery, viewing, downloading, embargoes, and leases

This document addresses multiple interrelated permissions deliverables for the Management FRG, including an inventory and analysis of DLP Repository user permissions needs for activities such as viewing, creating, editing, and deleting assets in the repository. A detailed matrix of system permissions functionality is provided in Appendix C, which references both native Hyrax software capabilities and anticipated Emory customizations. A mapping of out of the box Hyrax system roles to local user profiles developed by the Repository Management FRG and Deposit FRG is also included for reference (see Appendix A). Emory needs regarding levels of repository assets’ visibility (users’ ability to view and download repository content) are documented separately in Appendix B. Finally, user stories capturing unique permissions scenarios and general recommendations for implementation are also included in this document to summarize some unique scenarios identified during analysis of the matrix detail.

This document contains only abbreviated references to Hyrax workflow-level roles, such as Workflow Approver or Workflow Manager, because these roles may vary for each individual workflow implemented in the system. Mediated deposit workflow definitions have been established in the new Hyrax-based ETD application which can serve as a reference model for future workflow implementations to be configured during DLP Implementation phases.

The requirements identified here are subject to Hyrax software capabilities and Emory’s local capability to develop and maintain customizations. The details of the permissions matrix included in Appendix C are also subject to ongoing change based on Hyrax software releases and documentation availability: during the course of the Management FRG’s work, 3 new system roles were added which impacted the existing permissions model.

Work Process

While creating a work breakdown structure and analyzing tasks, the group made the determination to consolidate multiple permissions-related deliverables into one effort, since they were closely interrelated. As a preliminary step, the team conducting a three-part brainstorming session to identify repository entities, types of people/roles participating in long-term management of repository assets, and verbs/activities. This information was further refined to produce the Management User Profiles and also helped inform the matrix in Appendix C.

The group learned about current Hyrax system entities and permissions concepts, some of which were added to the team’s glossary. It is important to note that some Hyrax permissions information is undocumented, however. This gap is being addressed in the work of the Samvera Permissions Analysis Working Group. The Management FRG also reviewed work being produced in parallel by the DCSC Policy Task Force, Metadata Implementation Working Group, Digital Preservation FRG, and in order to identify entities and activities in scope.

Local Emory Needs/Potential Gaps

The following user stories, which reference role names based on the group’s Management User Profiles, capture local Emory needs which may not be achievable within the current Hyrax permissions model. These stories have been shared with the Samvera Permissions Analysis Working Group for appraisal.

As a Repository Administrator or Collection Manager, I want to assign permissions at the top level of an entity and have them propagate to their children, but be override-able at lower levels if needed, so that it is faster for me to assign permissions to appropriate internal staff users on a collection by collection basis
As a Repository Administrator or Collection Manager, I want self-service ability to assign and maintain a set of users within an existing permissions group, so that I don't have to request developer assistance or application redeployment to perform routine tasks
As a Repository Administrator, I want self-service ability to create a Group of users that I can assign to various permissions, so that I don't have to request developer assistance or application redeployment to perform routine tasks
As a Collection Manager, I want to manage a subset of groups and users relative to my immediate organization, so that I can more easily manage my Library’s staff permissions without having to request full administrator access to the application
As a Collection Manager, I want to restrict editing of selected parts of the digital object's metadata to specialized personnel, so that I can minimize unwanted changes to the object in its preservation state
As a Repository Administrator or Collection Manager, I want to be able to view individual staff/assistants user activity for users modifying objects/files in my collections/department only, so that I can contact a specific user about their work
As a Collection Manager, I want to run reports about analytics and inventory that are scoped to my Library or collection hierarchy only, so that I can exclude extraneous data about other Libraries' content and users
As a Repository Administrator, I want to restrict Deletion capabilities to Admins only or enforce via a workflow, because deletion is subject to local policy
As a Repository Administrator, I want to be able to deselect/select individual abilities assigned to a System Role in a self service capacity, so that I can customize default system Roles with less developer assistance
As a Repository Administrator or Collection Manager, I want to manage visibility and edit access to Preservation Workflow metadata related to a work, so that I can minimize unwanted changes to preservation audits for an object

The following Emory-specific user stories were also captured, but which may be achievable through minor customization or local configurations, and have also been shared with the Samvera Permissions Analysis Working Group:

As a Collection Manager, I want to assign a primary Library collection affiliation for a work, but be able to control its use in an Exhibition collection that might include works from other Library Collections, so that its source context is not lost if it is added to a user created or exhibit collection and so that I can manage permissions at the Collection-level
As a Repository Administrator, I want to constrain the types of Collections that Self Deposit/non-Library users create, so that user-created collections are not competing with Library-curated collections in search and discovery context
As a Collection Manager or Self-Depositor, I want to embargo sub-levels of the work, so that sensitive or proprietary details included in an abstract or table of contents for my work are not visible, but other metadata is
As a Repository Administrator or Collection Manager, I want to manage visibility and edit access to agreements/Deeds of gift or sale, so that this information is preserved but not editable or viewable except by selected staff
As a Repository Administrator, I want to generally delineate Library Staff/curating users from self deposit users, so that I can restrict certain system-wide activities to users who are Library staff only
As a Repository Administrator or Collection Manager, I want to restrict editing of selected parts of the digital object's supplemental preservation files to specialized personnel, so that I can minimize unwanted changes to the object in its preservation state

Additional Recommendations for Implementation

The following are identified as general considerations for DLP implementation:

Utilize the existing Hyrax product permissions model wherever possible to minimize complexity.
While some customizations may be possible, the current Hyrax model is complex and has been targeted for revision.
Design an Emory staff user group strategy that will help streamline the complexity of current state permissions in Hyrax. Developing a robust group model before content migration will help reduce redundant permissions assignments over time.
Consult with Samvera Community experts prior to implementing our Administrative Set and Collection configuration.
We will need to plan our Administrative Set and Collection structure (along with Collection Types’ configuration) carefully in advance: once a Collection has been created and is assigned a specific Type, it can’t be un-set. Collection Types are locally customizable and enable assignment of certain functionality, such as whether or not a Collection is nestable, discoverable, and what types of permissions can be assigned.
Continue to work with the Samvera Permissions Analysis Working Group to improve the current permissions model. Emory currently has representation in this group, which will propose significant changes to how permissions are currently assigned and managed in the Samvera technology stack.

Appendix A: System Roles Analysis - Hyrax and Emory

The following table lists out of the box Hyrax software system roles, noting correlation to Emory DLP User Profiles where applicable. In general, individuals with accounts in the repository will be assigned multiple system roles in order to perform necessary tasks.

ID	Name	Abbrev.	Source	Scope	Description	Emory Profile Equivalent
R1	Public Viewer	Public	Hyrax	Front-End	Any visitor to the web front end	Content Display FRG Profiles
R2	Authenticated User	Auth User	Hyrax	System wide	Any registered user logged in at the time of the activity. (This does not imply Emory network visitors)	Any user with a repository account
R3	EUL System	EUL System	Emory	System wide	Indicates a local Emory customization/system activity	N/A
R4	Repository Administrator	Repo Admin	Hyrax	System wide	Hyrax: “Can see, edit, delete all works, collections, admin sets regardless of access controls and workflows on the objects. Also can modify Repository Configuration options in the UI.”	EUL Repository Administrator; EUL Repository Engineer
R5	Administrative Set Manager	AS Mgr	Hyrax	Admin Set	Hyrax: "Can see and edit all works in the set regardless of visibility settings on the individual works. Can change the details about the Admin Set itself."	EUL Collection Manager
R6	Administrative Set Viewer	AS Vwr	Hyrax	Admin Set	Hyrax: "Can see items in the set regardless of visibility settings on the individual works. These can be viewed by searching for the works. Viewers can not navigate to Admin Sets via the dashboard."	N/A
R7	Administrative Set Depositor	AS Dptr	Hyrax	Admin Set	Hyrax: "Can deposit to the Admin Set. Clicking Allow all registered users, allows anyone who logs in the right to deposit to that set. This might be useful for Admin Sets like “Open Access Articles”'	EUL Self Depositor; EUL Collection Manager; Library Staff Depositor
R8	Collection Manager	Coll Mgr	Hyrax	Collection	Hyrax: "Managers of this collection can add to and remove works from the collection, modify collection metadata, and delete the collection." [in advanced configurations] “when works are created directly in this collection, managers are given edit access to new works”	EUL Collection Manager EUL Metadata Specialist
R9	Collection Creator	Coll Crt	Hyrax	Collection Types	Users or groups in this role have the ability to create collections of a given type	EUL Collection Manager
R10	Collection Depositor	Coll Dptr	Hyrax	Collection	Hyrax: “Depositors of this collection can view the collection and add works to it, even if the visibility permissions of the collection otherwise would not permit them to view it.”	EUL Collection Manager EUL Self Depositor EUL Library Staff Depositor
ID	Name	Abbrev	Source	Scope	Description	Emory Profile Equivalent
R11	Collection Viewer	Coll Vwr	Hyrax	Collection	Hyrax: “Viewers of this collection can view it even if the visibility permissions of the collection otherwise would not permit them to”	N/A
R12	Work Editor	Work Edr	Hyrax	Work	[no Hyrax documentation - assume an individual user or group that can modify a selected Work]	EUL Self Depositor; EUL Metadata Editor; EUL Collection Manager; EUL Preservation Curator; EUL Metadata Specialist
R13	Work Viewer	Work Vwr	Hyrax	Work	[no Hyrax documentation - assume an individual user or group that can view a selected Work]	N/A
R14	Workflow Reviewer	Wkfl Roles	Hyrax	Workflow	[no Hyrax documentation; may vary per each workflow defined]	Academic Program Deposit Mediator
R15	Workflow Approver	Wkfl Roles	Hyrax	Workflow	[no Hyrax documentation; may vary per each workflow defined]	Academic Program Deposit Mediator
R16	Workflow Depositor	Wkfl Roles	Hyrax	Workflow	[no Hyrax documentation; may vary per each workflow defined]	Student Submitter Faculty/Researcher Submitter Campus Staff Submitter
R17	Workflow Manager	Wkfl Roles	Hyrax	Workflow	[no Hyrax documentation; may vary per each workflow defined]	Library Deposit Supervisor Academic Program Deposit Mediator

Note: the new Emory ETDs application also has a “superuser” role defined which can manage all ETD-related Admin Sets, edit all ETDs, and approve submissions from all workflows. This document also consolidates Workflow-related roles into one entry, because these may vary per each individual workflow configured. The Laevigata application can serve as a reference for future production workflows.

Permissions Assigned via Users and Groups

In addition to the abilities assigned to the System Roles outlined above, Hyrax software also enables the assignment of permissions to individual users as well as to groups of users for interacting with specific entities such as collections, objects, files. In particular, groups of users may be assigned to a given system role (instead of assigning individual users), which can help us coordinate permissions assignment. For example, a pre-defined group of individual users from Rose Library could be assigned to the Collection Manager system role for a particular Admin Set or specific collection, as opposed to assigning each individual separately to that role context.

Appendix B: Visibility Levels

The functional requirements noted inform levels of visibility that the system can enable; actual assignment of visibility to material is subject to Emory Libraries policy and procedure. Hyrax documentation indicates “Visibility only controls who can view or download your work – it does not control edit access.” When view permissions are assigned for an object or file, those same settings apply to download options.

Standard Hyrax Software Levels of Visibility:

Public: Public makes the work available to the general public. Metadata is available to be crawled by search engines for discovery.
Institution: restricts access to works and work metadata to users with login privileges. Users will need to be logged into the repository to access the work. (Note: Institution does not mean the Emory campus network: it means that any authenticated/internal repository system users can view it, relative to other settings assigned at the Admin Set or Collection level.)
Embargo: lets you restrict access to Private or Institution until a specified date, when it will be opened to the public or your institution
Lease: permits access to the work to the public or Institution until a specified date, when it will be restricted to Private or your institution
Private (Note: this status is not fully documented, but appears to mean only visible to the work owner or Administrator only)

Emory Visibility Customizations Requested

IP-range restriction for Reading Room access
IP-range restriction to restrict visibility to Emory campus network users only (Emory network/VPN connection required to view)
Custom embargo duration lengths

ETDs: 6 months, 1 year, 2 years, 6 years
Emory FIRST to OpenEmory embargo durations: 6 months, 12 months, 18 months, 24 months, 36 months, 48 months, Indefinite.
Ensure open-ended date ranges (Hyrax default) are also available for Libraries’ Admin Sets/Collections

Custom embargo for sub-object levels: (e.g. ETDs)

Embargo content files
Embargo content files and Table of Contents
Embargo content files, Table of Contents, and Abstract

Appendix C: Permissions Analysis - Matrix of Entities, Activities, and System Roles

See e xternal document. The tables document basic Hyrax functionality as well as anticipated custom functionality for the DLP repository application(s) to provide, and are broken out into sections reflecting different categories of repository system entities:

Content Entities: Collections
Content Entities: Objects and Content Files
Content Entities: Object Supplemental Metadata & Preservation Files
Permissions-related Entities
Other/Administrative Information Entities

The matrix entries were based on known DLP requirements produced by other FRGs as well as available permissions-related documentation in the Hyrax Developer Knowledge Base, primarily the Manager’s Guide for version 2.x.

Browser not supported