Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

DRAFT

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.


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

  • action levels (column B) - "Levels" are based on two concepts:
    • There is a hierarchy of objects with site being the top level: A collection type 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) - 
    • a list of ALL available (or desired) site actions at each of the levels
    • broken down to the point where the ability to access the action needs to be conferred to the users independently of 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
    • repository users - documenting the permissions which are currently predefined in the Hyrax system
    • institutional users - documenting the use cases identified by various institutions
  • state access (column E) - access may vary according to state of object
    • 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?

Context

  • No labels