...
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:
- action 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.
- "Levels" are based on two concepts:
- 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
- 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 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) - access may vary according to state of objectmeans 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.
...