2018-06 - Community Report Back and Request for Input

Owned by Jeremy Friesen
Last updated: Jun 13, 2018 by LaRita Robinson
3 min read

This is a request for a community review of the Permission Matrix, a document synthesizing and normalizing the actions, action levels, and possible user types of various Samvera-based implementations.

We are working through PAWG - Use Cases to Permissions Matrix Followups to ensure we've fully captured and understand our initial round of use cases.

Introduction to the Permission Matrix

We envision a configurable permission system that allows an institution to create their own roles and assign to each role whichever actions are relevant to them. In working toward this goal, the PAWG has gathered the permissioning needs of various Samvera-based implementations. 

We are presenting the Permission Matrix as our attempt at synthesizing and normalizing these actions, action levels, and sample user types. It is important to capture all the actions that we would like to be able to atomically assign to roles more so than whether we have all current institutional roles listed.

We hope that you can provide feedback on our work as a whole, but the most important components we need feedback on are Actions (column D) and State Access (column E) in the Permissions Matrix. These are described below and in the spreadsheet. 


The Permission Matrix introduces some new concepts, which are also explained in notes attached to the spreadsheet cells:

  • Object levels (column B) - The level of the object you can act upon, for example "Collection Type".
    • "Levels" are based on two concepts:
      • There is a hierarchy of objects with site being the top level: A collection type is an object that is added within a site. A collection is added within a collection type.

      • Abilities are object-based: Users may have the ability to create a work, but not create a collection.

  • actions (column D) - the ability or action you can take on an object at a given level, for example "Edit permissions". 
    • a list of ALL available (or desired) site actions at each of the levels
    • granular actions, so that permissions to each action can be granted separately from other actions
  • user types (row 8, columns G-AA) - users grouped into three categories
    • authority users - documenting the permissions are conferred solely by signing into site
    • hyrax users - documenting the permissions which are currently predefined in the Hyrax system
    • institutional users - documenting the use cases identified by various institutions (this might be institution specific users, defined by a given institution)
  • state access (column E) - means that the ability/action only applies when the object is in a particular state (for example, reviewing papers)
    • the state is monitored for objects using workflows (currently at works level)
    • workflow actions are intended to be generic, to allow for new workflows to be added. it is assumed that the actions at the state level need to be independently permissionable, so a Works Level action of "Other workflow action" was included to indicate this.

Questions

  • What can we clarify to help you better understand the Permission Matrix?
  • What actions, action levels, or user types are we missing?
  • Are the actions and their target objects granular enough?
  • Are we missing conceptual item levels?
  • Do other objects or levels need to include state access considerations?
  • What other things can we clarify regarding our Permission Analysis work?

How to Give Feedback

You may respond to the Google Group threads or add comments to the Permission Matrix sheet. Clarifying questions may also be asked in the #PAWG slack channel.

What is the Timeframe for Feedback?

We look to close the window by end of day Wednesday July 18th.

Context