Meeting Logistics:
- Time: 10:00am PDT / 1:00pm EDT
ZOOM connection: https://notredame.zoom.us/j/94030214208
(link will launch Zoom client – if you do not have Zoom, expand the instructions below)
Agenda
(meeting notes below)
- Topics from May 2021 Dev Congress
- Hyrax ACL & Authorization Group Whiteboarding
Facilitators: Lynette Rayle, tamsin johnson, Jeremy Friesen
Notetaker: Juliet Hardesty
Attendees:
- Jeremy Friesen
- Daniel Pierce
- Chris Colvard (Deactivated)
- Maria Whitaker
- Michael Johnson
- Jon Cameron
- you
- you
Meeting Process
Notes
- select one topic for today - ACL & Authorization Group
- Nested Indexing will be tomorrow
- Work is not visible to owner in a mediated workflow if embargo selected - https://github.com/samvera/hyrax/issues/3817
- more discussed in issue regarding permissions than just this described issue
- short-circuiting ability class
- controller logic doesn't necessarily make sense for why you would be there
- sipity workflow lands you in this spot, it looks like
- implementation rule suggestion: way we determine object level access is through ACL only
- object has ACL with permissions assigned (mode and agent/user/group)
- ACL handles read, discover, edit over users and groups
- always positive access grant
- this issue creates circumstance where particular user (depositor) does have read access even though there is no ACL that grants that access - that should be wrong if we go with ACL-defined access
- one caveat: Fedora has object status (inactive or active) - Hyrax only uses inactive and that underlies "suppress"
- ACL and suppress flags are re-implemented in Valkyrie adapters, by the way
- how is strictly following ACL problematic?
- IU and Avalon permissions are not necessarily just object level permissions so there are other things to consider
- object permissions should maybe refer to repository object permissions (PCDM-level considerations, so file or fileset or collection or repository object)
- sipity workflow and its understanding of permissions
- state machine that sipity knows is state of workflow (so not Fedora active/inactive object state)
- knows who can take an action for a given workflow state