2024-02-09 Meeting Notes
Attendees:
@Jeremy Huff
@Dale Arntson
@Joseph A Molloy
@Lloyd Chittenden
@Maccabee Levine
@Robert Heaton
@Amanda Ros
@Ian Walls
@Kevin Day
Annoucements
Introduce @Amanda Ros as co-chair
Updates from @Jeremy Huffon dev team activity: sprint wrapping up, mostly backend work that’s less visually demonstrable
How should permissions work in Workflows?
Should workflows run under the user that started the workflow, created the workflow, or as a dedicated workflow super user?
Should all three of these be options when creating a workflow, should this be configurable?
How do other institutions handle permissions during automated processes?
Discussion
Joseph M:
classifying workflows by institution (1-5 scale?) and user permission granted separately for creation and execution per classification. One staff creates it, another approves it before it’s made executable.
Jeremy H:
love that idea
Amanda R:
Also like this idea
Lloyd C:
good in many cases, but some users should not require an approval to run a workflow
Robert H:
there is a model in the Orders App for whether workflow executions require approval or not (tenant level config)
Jeremy H:
are the two options mutually exclusive? Tenant level would override, but not in a harmful way, so safe to have both ways
Joseph M:
creation of workflow is more important to approve, because it may be very sensitive or resource intensive.
Dale A:
would the execution be as a super-user?
a: yes
Lloyd C:
how are sensitivity levels (classifications) determined? By the creator?
a: yes, and that’s why the approval step is necessary, so the approver can determine if the level is correct
Dale A:
what specifically does ‘sensitivity’ mean, in contrast to ‘complexity’?
Jeremy H:
what about a different term? need to be flexible about not encoding institutional policy into the system
Ian W:
could we limit what workflow components a user can build with based on what permissions they have?
a: yes, but technically difficult. API interactions are permissions-governed, but database interactions aren’t.
Robert H:
seems similar to some conversations had in BELA.
a: we should coordinate with that group, as well as App Interaction
Jeremy H:
how do Bulk Edit and Lists handle permissions?
a: Amanda will check in with BELA and Magda about this
Dale A:
might this create a permissions “back door” that can circumvent the normal permissions system?
Jeremy H:
what about an ‘allow list’ of users who can run which workflow?
Ian W:
one permission to create, including the assignment of who (individually) can run?
a: yes, and include the concept of ‘approver’ permission so we can get two sets of eyes on it. institution could assign both permissions to one person, but that would be an intentional choice
Robert H: (via chat)
I understand there’s talk of “roles” to which permission sets can be assigned. The idea of assigning individuals to a workflow could readily be ported to that role-based model as well.
Kevin D
nothing here seems infeasible
Ian W:
in the workflow system I work with most, workflow definition is separate from credentials. Nodes need to be connected to appropriate credentials to be able to run, and users are given access to those credentials (or not), so workflows, which run as the logged in user, not a generic superuser, will only run if that user has access to the necessary credentials
Jeremy H:
demo of current system; login as a specific node in the workflow
Robert H:
could the workflow do the login multiple time with multiple users for different steps?
a: yes
Dale A:
mid-stream logins create the possibility for a lot of breakage, especially as FOLIO grows and evolves. Perhaps check permissions before execution to verify it will actually run?
Jeremy H:
practically, the path of least resistance and most likely to be done by institutions is to make a superuser with all the permissions necessary and use that, instead of multiple users and switching between.
Joseph M: (via chat)
Curious how scheduled workflows interact with the login prompt/process?
a: login node can always perform it’s login task, persisted rather than dynamic. changing superuser credentials would break all the associated workflows. so user input would not be required per execution
Dale A:
is there a performance issue with multiple, iterative logins as a workflow executes?
a: since the login is persisted, the subprocesses do not need to conduct the login each time, saving this performance hit
Action items:
Jeremy H will continue documenting
Discussion will continue in Slack