Overview Expected delivery October 2018 Recent progress ● Incorporating additional use cases in the Permission Matrix ● Wrapping up Permission Matrix Biggest risk Transitioning from analysis and requirements gathering to technical design and implementation
Problem We're Solving Inflexibility ● Current permission implementation requires downstream developer involvement to modify ● Vulnerable to upstream change ● Mixture of "can?" and "is_a?" permission checks Opacity ● Cannot easily answer "Who can take the given action on the given object" ● Mixture of permissions on objects vs. in configurations
Problem We're Solving Incomplete Use Cases ● Current permission implementation no longer reflects the more extensive permission use cases of the community Inadequate Documentation ● Ambiguous how to modify my institution's permissions in a sustainable way
Deliverables Context Summary ● A one page summary of the current state of permissions in Hyrax Requirements Gathering ● Spreadsheet of submitted use cases ● Permission matrix to distill the use cases into a visual format of individual permissionable actions
Deliverables Requirements Synthesis ● Documentation of current gaps in the existing permission system - included in Permission Matrix and Design Objectives Design Objectives ● An implementation allowing repository actions to be permissionable and configurable ● Document listing design objectives
Process - How We Got Here Step 1: Gathered Information ● Reviewed Notre Dame’s prior analysis ● Discussed variety of problems which we needed to solve ● Solicited use cases from organizations participating in working group ● Gathered use cases in a common spreadsheet format
Process - How We Got Here Step 2: Organized Information ● Distilled common use cases into the Permission Matrix: a collection of individual permitted actions in a visual format ● Presented Permission Matrix to the community for feedback ● Added new actions based on community feedback
Process - How We Got Here Step 3: Analyzed Information ● Identified gaps in the existing permissioning system ● Identified objectives for a new permissioning system to be a success
Next steps Undelivered Deliverables ● We did not get to the design stage - we realized that our team composition lent itself to analysis and use-case gathering, and less towards system design ● Recommendation: A timeline and supplemental documents from which the community to further design out, develop, and implement the synthesized requirements.
Next steps Wrap Up Analysis Working Group Final report at Samvera Connect 2018 Pass the Baton Charter a new working group with an eye towards design and implementation ● Should we do this? What happens if we don't? ● Who should (and can) lead this?
Question for the Community What additional information do you need to make a decision as to whether to invest (or not) in designing for and implementing these functional requirements?
Further Information Working Group Home Page ● Original Charter ● Meeting Agenda & Minutes ● Additional Documentation ● https://wiki.duraspace.org/display/samvera/Samvera+Permissi oning+Analysis+and+Design+Working+Group