Versions Compared

Old Version 5

changes.mady.by.user Craig McNally

Saved on

compared with

New Version 6

changes.mady.by.user Craig McNally

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes
1 minScribeAll

Craig McNally will take notes

< 10 minQuestions from previous session?AllNothing was added to the previous session's notes.  Are there any questions before we proceed?
*

Platform & Application Formalization

Vince

Background:

Notes:

  • Introduction was given
    • This is a slight departure from the previous two sessions which focused on application and platform formalization
    • Touched on the principle of least privilege  
    • Managing and auditing permissions is difficult - you get a flat list of (usually visible) permissions/permissionSets.
    • Folio has patron groups, but doesn't have staff groups → having this would be helpful for enhanced consortia support
      • It was acknowledged that patron groups are not used for authorization.
      • patron / staff groups are more about organizing/grouping users
  • Overview
    • Terms were introduced:
      • Capability
      • Role
      • Policy
    • Maccabee Levine:  It seems to me that this already exists, but with different naming
    • VBar clarified that while that's true in some cases, policies are NOT currently possible, and one part of this is bringing additional consistency to the system and simplifying things
  • Deeper dive into capabilities
    • Marc Johnson: A lot of this has already been modeled by SIGs, etc.  There may not be much of an appetite to "redo" that work
      • VBar:  This is at a different level, we'll get to this a bit later in the presentation.
    • Marc Johnson: Related to procedural capabilities, what does the "execute" action actually relate to?
      • VBar:  These capabilities relate to the granular (BE) permissions/APIs 
      • Marc Johnson:  Like Maccabee, I think we already have this
      • Marc Johnson:  A capability on it's own doesn't provide everything a user needs to actually do what they need to.  That's where roles come in.
    • Marc Johnson:  If capabilities are fundamentally a backend thing, why would we create a UI experience for granting those in the UI?
      • VBar:  This is an attempt to simplify the management and auditability of privileges granted.
      • VBar:  Roles provide a way to roll up the capabilities as needed into a single thing which can be assigned to a user.
      • VBar:  There is a notion that we need to introduce something along the lines of a capabilitySet, but details have not been sorted out yet.  The hope is that some of this will be ready to discuss at WOLFcon.
  • Deeper dive into roles
    • At this point we began running out of time, and deferred questions until the end.
  • Brief Q&A:
    • Jenn Colt acknowledged that improvements are needed to how permissions are managed, why can't we just make those improvements on what we have, instead of undertaking a larger "redo"?
    • Maccabee Levine reminded us that there are functional and other considerations here that we shouldn't just focus on technical aspects of this.
  • The plan for addressing questions which we didn't have time for is to capture them below and VBar  will try to answer them at the next TC meeting ( )
-QuestionsAll

Place to ask questions not answered during the presentation.  To be answered later (e.g. at the next TC meeting).

  • ... 

Zoom Chat-

Marc Johnson  to  Everyone 11:10 AM
How are patron groups used for authorisation? It is my understanding that isn’t what they are used for

Maccabee Levine  to  Everyone 11:13 AM
"Roles" to me sounds like the existing "Permission Sets".  I assume the next slides will explain the diff

Marc Johnson  to  Everyone 11:21 AM
IIRC one of the reasons that FOLIO does not have canned roles out of the box is that each organisation models their roles differently  And thus canned roles would only add noise

Marc Johnson  to  Everyone 11:32 AM
I don’t think I understand, because granting back end capabilities is NOT the same as granting capabilities in the front end 😕

Jenn Colt  to  Everyone 11:35 AM
Capabilities are equivalent to “hidden permissions”?

Maccabee Levine 11:36 AM
And we are now un-hiding them?  This has major functional implications.  Big increase in complexity.

Jenn Colt 11:37 AM
I see the appeal of making them clearer when you need to see them. I’m not really getting the language/modeling change.

Maccabee Levine 11:38 AM
"When you need to see them" I think is the functional question.  As Marc just said the granularity of these backend permissions (currently hidden) is much greater than FE.

Jenn Colt 11:39 AM
Right. When we have set up integrations we have messed with them. Also when dev forget to put them in their UI sets…

Marc Johnson 11:40 AM
If roles are made in the UI, these capabilities would need to be un-hidden

Marc Johnson  to  Everyone 11:47 AM
What is an example of a role? My classical understanding of a role is something like “circulation desk staff”. However the impression I’m getting here is that a role would be more like “can edit instances” or “can check out an item”.

Jenn Colt  to  Everyone 11:48 AM
Right I’m still not getting why this isn’t just a best practice recommendation + addition of perm set to the user facets UI. Why. Can’t policy be an add on to the existing system

You  to  Everyone 11:48 AM
I think a role generally would align with things like circulation librarian, acquisitions manager, etc.

Marc Johnson 11:50 AM
That doesn’t fit with how I interpreted Vince’s explanation of them

You  to  Everyone 11:50 AM
Vince mentioned that he thinks there's still a need for visible and invisible capabilities

You  to  Everyone 11:51 AM
In my mind, it would be possible, if desired to see invisible capabilities in the UI, but they'd be hidden by default.  Much like we have with permissions in the UI today.

You  to  Everyone 11:50 AM
Marc I think what you're missing is the capabilities are defined by backend modules.  These are typically not visible in the UI.  There will need to be something else (e.g. capabilitySet) which is a grouping of those which would generally be visible in the UI.

Marc Johnson 11:52 AM
Vince just demonstrated a UI for exposing capabilities to a user via the UI  Which means that doesn’t fit with how I interpreted Vince’s model. And the proposed model doesn’t have capability sets. Which is what I interpreted Vince as describing as roles. It seems you have a very different model of this than what is described in this deck / presentation

You 11:53 AM
We've been discussing the topic, but details haven't been sorted out yet (hence the presentation not mentioning capabilitySets)

Marc Johnson 11:54 AM
Sure. That makes it confusing for folks like me when you and others are operating on a different understanding of the model than what is being presented

Maccabee Levine  to  Everyone 11:54 AM
Vince, do the backend and frontend modules still check for *permissions* before doing X operation, or do they ever check for capabilities?

Marc Johnson 11:55 AM
If this is an optional layer on top of what we already have, then the system would still have to depend upon permissions

Maccabee Levine 11:55 AM
I agree, just want to confirm with Vince -- I'm not missing another "next level" idea

...