Attendees

Jeremy Friesen Maria Whitaker LaRita Robinson Rob Kaufman JP Engstrom Chris Colvard (Deactivated)

Agenda

Review previous agenda: Hyrax Permission Working Group - 2020-01-06
Disucssion regarding homework:
- Review the Hydra Roles & Permissions document (which may be useful to also review the Permission Matrix).
  - We are looking to answer two primary questions:
    - Is the ERD adequate to handle the use cases?
      - What could be removed?
      - What is unclear and could be clarified?
      - Can we fold state into the action? What would that mean for the state machine?
    - What does each specific UI element look like to grant the permission identified in the Permission Matrix? That is to say "What does the UI look like to grant someone the ability to Create an Admin Set? What does the UI look like to grant someone the ability to create a work into the given Administrative Set?"

Minutes

We reviewed the Hydra Roles & Permissions document. Observations were around complexity in its flexibility. Can we cut portions to make it less complex? Is the change complex? Or the system, by necessity, complex?

We all agreed that we want the application logic on permissions to run through the Ability class (and if implemented, delegate questions down into the database that we've been discussing).

There exist some observed complexities:

The existence of granting permission to groups and individuals creates a layer of complexity. As part of the discussion, we addressed that existing Hyrax provides user and group grants. Aspirationally, we would like everything to be granted by way of a group, however that adds a possible complexity to the researcher that opts to add a grad student as an editor to the researcher's work.
Ability file provides a singular place that we could leverage, there exist lots of `is_a? :admin` questions in views, presenters, controllers, etc (parts of the business logic of Hyrax)
<Sorry Rob Kaufman I missed the 3rd observed complexity>

We discussed the fundamental question of permissions: Who can take the action on the given object in its current state?

There are typical questions that must be asked:

For the given user and given object and its current state can I take the given action?
- Examples: Ensure that only the right people can make edits to an object
For the given object in its current state who all can take the given action?
- Examples: We want to know who can edit the object, We want to send an email to all of the people that could approve the object in its current state (and thus move it to a new state)
For the given user and the given object and its current state, what actions can I take?
- Example: I can approve a work or send it back for revisions (both of which are actions)
Rob Kaufman you had some additional ones and mentioned that they could be folded into each other.

What in the ERD could we collapse?

Permission Grants (Entity, Scheme, and Power grant) - The Power grant is theoretical (e.g. this agent always has the given role across all contexts). The Scheme grant should exist so that we can say "The Grad School's ETD manager can edit all works part of the Grad School's scheme" The Entity grant should exist so that we can say "The Researcher that deposited this work can edit this work (but not other works)."
LaRita Robinson - Can you speak to the Role >-< Duty relationship? Namely the advantages for not collapsing that?
Duty / Scheme - A Duty is a named responsibility of work (cataloging, approving, etc.), by creating a join between Scheme and Duty, we provide the ability for multiple workflows to have a similar responsibility of work (e.g. approving) that may manifest differently by each scheme. For example, the approving Duty in scheme 1 may be able to approve in the work at any state, which then sends it to a final state. For the approving Duty in scheme 2, the approver only approves in the step "Waiting for Approval".

We have high level work that we could do:

Consolidate all current permission checks into the Ability class (e.g. move all `is_a? :admin` questions into the ability class by way of a `can :<action>, :<object>`
Migrate the existing Sipity models to the new format
Create UI for managing these things

Action Item

Jeremy will schedule next meeting and seed minutes
Jeremy will work on UI sketches for some of the administrative elements

Browser not supported