use cases in the Permission Matrix • Wrapping up Permission Matrix Biggest risk Transitioning from analysis and requirements gathering to technical design and implementation
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
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
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
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
• 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
• 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
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.
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?