2024-02-09 Meeting Notes

Owned by
Ian Walls
Feb 09, 2024
3 min read

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