2024-03-22 Meeting notes

Dev update

Jeremy, Kevin

• working on updating module to use Spring Module Core. Some setbacks and folks were ill, but includes a demo of some of the UI.

Permissions

Jeremy

Conversation ongoing. Jeremy working on user stories.

Question: work on security concerns?

Runtime relationships need to be established, and we need to do diligence to make sure that’s responsibly handled.

A consideration: EBSCO has a proof of concept for a new authentication mechanism that offers some additional granularity of permissions (ie permissions to only run at a certain time, one-time permissions, etc)

Currently running as a super-user, which obfuscates some of the details about who actually ran the workflow. Common enough in reality to have users with more rights to the system than they really need, but permissions issues can easily create barriers to getting work

Jeremy’s permissions idea:

One task node that handles login/logout as well as API request itself. Dropdown of every single endpoint in Okapi as part of node definition. This allows the whole workflow to understand what permissions are required to run, so it will create proxy permissions for those. A user must then have those proxy permissions to run the workflow, even if they cannot actually have the permission normally.

Q: why use proxy permissions to modules rather than per-workflow permissions?
A: sounds like access lists idea (like @Joseph A Molloy mentioned early on). Implied permissions should be exposed. The reason proxy permissions were proposed was to keep a similar permissions paradigm to the rest of FOLIO.

Having create permissions for workflows allows one protection. Using approval method provides another (especially to be sure deletes aren’t run erroneously)

Some reaction to EVERY endpoint being exposed… could that be filtered a bit to help reduce risk?

Using Permissions Sets to help bundle.

Namespace conflict possible; ‘workflow_okapi’ as prefix.

Idea: having individual modules identify which endpoints they want to expose to Workflows…. lots of distributed work to make this possible

Acquisition Units paradigm: users can be assigned to multiple units, and then records connected to those acq units. You need permissions to do an operation, and to be part of the records unit

In Dashboards, users are associated with individual dashboards directly instead of through a team.

GBV working with Knowledge Integration on how to do teams as a FOLIO-wide solution, 3-6 month timeframe.

ERM/Workflows Proposal

@Owen Stephens @Martina Tumulla

ERM community has workflows, represented in Trello boards or in CORAL. Similar to what we mean by “workflows” in this group, but a little different. For example, CORAL can have a ‘renewal’ workflow, which has a mix of automated data munging and human inputs.

Fundamental question: What are the tasks/processes that the ERM community are using, and what would that look like in the mod-workflows context?

Human-decision steps are critical to making workflows be successful; we just haven’t gotten to the UI portion of the work to show this off (but it’s all possible). A To Do app has been floated, as well as a Dashboard widget, which may be a lower barrier to entry. EBSCO has a Tasks App, but the current status is unclear.

Based on this conversation, looking for this to be a half-day workshop/brainstorming session to move this concept forward. If this is going to be a pre-conference session, need to speak up soon so folks can plan their travel.