[FOLIO-3253] SPIKE - Investigate minimal FOLIO platform Created: 28/Jul/21  Updated: 10/Oct/22  Resolved: 10/Oct/22

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Craig McNally Assignee: Zak Burke
Resolution: Done Votes: 0
Labels: platform-minimal
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-1730 Create folio/minimal Vagrant box Open
is blocked by MODUSERBL-153 leverage optional okapi dependencies ... Closed
Gantt Start to End
earliest end is start of FOLIO-3548 Verify and fix platform-minimal Closed
Relates
relates to MODUSERBL-153 leverage optional okapi dependencies ... Closed
relates to STCOR-602 login directly via mod-login instead ... Closed
relates to STCOR-642 publish DID_LOGIN event Closed
relates to STCOR-650 remove service-point handling Closed
relates to STCOR-649 store raw login response details in ... Closed
relates to UISP-32 on login, insert service point detail... Closed
relates to FOLIO-3337 Replace use of release-core at Tutori... Blocked
relates to MODUSERBL-155 Spike: Investigate current implementa... Closed
Sprint: Prokopovych - Sprint 131, stripes-force 150, Prokopovych - Sprint 133, stripes-force 147, stripes-force 148, Prokopovych - Sprint 134, Prokopovych - Sprint 132
Development Team: Stripes Force
Release: Nolana (R3 2022)

 Description   

Overview

The Tech Leads group has identified a desire for a minimal platform. That is the minimal set of modules/interfaces required to have a operable FOLIO system that you can log into.

More details can be found on the wiki .

Acceptance Criteria

  • Findings are documented on the wiki
  • The decision log page is updated with a link to the findings
  • The set of modules comprising a minimal platform has been identified, validated to provide a working system that satisfies the minimum functionality (defined below)
  • The functionality provided by the minimal platform should allow a user to log-in via the Stripes UI and allow to manage users and permissions. Modules that are not directly involved in providing that functionality should not be part of the minimal platform.
  • Generic UI services like Notes, Tags and Password Validation should be made optional by letting the Stripes UI to omit functionality.
  • Any functionality that belongs to a specific functional unit (e.g service point selection) should be optional.
  • JIRAs have been created for possible actions we can take to slim down the list even more, e.g limiting mod-login's dependency on the inventory APIs, mod-users-bl dependency on the service-points API
    • These JIRAs should be linked to the wiki page created.

Starter for 10 Module List

Provided by steve.osguthorpe might be out of date

  • mod-users
  • mod-configuration
  • mod-permissions
  • mod-login
  • mod-pubsub
  • mod-circulation-storage
  • mod-inventory-storage
  • mod-password-validator
  • mod-authtoken
  • mod-event-config
  • mod-template-engine
  • mod-email
  • mod-sender
  • mod-notify
  • mod-users-bl
  • mod-patron-blocks
  • ui-users


 Comments   
Comment by Marc Johnson [ 08/Mar/22 ]

Zak Burke Now that you are no longer part of this Prokopovych team, should this issue be removed from the team (and sprint)?

Comment by Jakub Skoczen [ 09/Mar/22 ]

Zak Burke Craig McNally IMHO, platform-minimal should be much smaller than what's included on Steve's list. It would be great if we could limit it down to:

mod-authtoken
mod-permissions
mod-login
mod-users

And if that's not possible extend the set to include:

mod-configuration
mod-users-bl

mod-password-validator

Comment by Zak Burke [ 09/Mar/22 ]

Correct, Jakub Skoczen, I was able to build a UI bundle and authenticate with only the following backend modules running:

  • mod-authtoken
  • mod-permissions
  • mod-users
  • mod-login
  • mod-configuration

I need to do some additional work in stripes-core so that certain values (the user's service points) currently pulled from a mod-users-bl API request into the session can be handled by some other means.

Comment by Zak Burke [ 09/Apr/22 ]

Jakub Skoczen, it occurs to me, belatedly, that we'll need _self endpoints on several interfaces (permissions, users, service-points-user at least, maybe groups too) in order for users to retrieve their own settings from those interfaces. All you get back from authn/login is a token.

Comment by Jakub Skoczen [ 06/Jul/22 ]

Zak Burke Another approach is to keep mod-users-bl as the dependency in platform-minimal but remove or relax its dependencies on non-critical modules. E.g remove the service points from the _self response and fetch them independently. Thoughts?

Comment by Marc Johnson [ 06/Jul/22 ]

Jakub Skoczen

remove the service points from the _self response and fetch them independently. Thoughts?

As I understand it, a characteristic of the login endpoint is that it requires no permissions to access it, yet it has permissions to fetch service points (and how they are associated to users).

If we remove these integrations from this endpoint, we would need every user to have permissions to fetch that information for themselves. As the APIs stand today, that would mean that all users would be able to fetch all service points and all of the associations between users and service points.

I believe the reason we want to do this is to reduce the necessary dependency on mod-inventory-storage in order to log in. In effect, it would shift to being an optional dependency.

I believe there have also been recent changes to Okapi / mod-permissions to only allowing granting of permissions to users when the permission exists.

Permissions are defined as part of the module (they are in the module descriptor) and thus granting permissions requires the module to be enabled. Granting the permission will fail if the module is not enabled for the tenant.

How wrong is my understanding?

(assuming I'm my understanding is reasonable) this presents a few challenges:

  • it is an escalation of permissions beyond what is essential
  • it present a bootstrapping challenge that every user needs to be granted these permissions
  • that bootstrapping will fail when mod-inventory-storage is not enabled
Comment by Zak Burke [ 06/Jul/22 ]

For the UI to function, it needs some basic information about the currently-authenticated user. At bare minimum this means permissions, some additional info (e.g. first name, lastname) is probably required right now but could be made optional. At present, it gets this in response to requests to bl-users/login and bl-users/_self. I see two options:

  1. mod-users-bl is included in platform-minimal but is updated to make most of its deps optional. This allows login and _self to function as-is, providing responses that are more or less hydrated depending on which optional deps are present. Minimal/no changes are necessary in UI-land. There's a bunch of code related to service points that really doesn't belong in stripes-core, but since the data it manipulates comes back from mod-users-bl it doesn't technically rely on an additional interface such as inventory.
  2. New, permissions-less _self endpoints are added to mod-users, mod-permissions, mod-whatever. This requires a bit more UI work (and mod-whatever work to add _self wherever permissionless, per-user info is available) but it arguably provides better separation of concerns (though I can't say if separation of concerns is a valuable attribute here; you could argue one-stop-shopping for all user attributes is valuable too), and we'll need to do most of the UI work anyway to move handling of service-points out of stripes-core. 

In short, some very similar UI work needs to happen either way. I don't have strong feelings about which one is better, but it's clear to me that some mod-users-bl (and possibly mod-other-things) work is required no matter what. 

Comment by Zak Burke [ 17/Jul/22 ]

Jakub Skoczen, as above, it doesn't matter to the UI whether it authenticates against mod-login-bl and gets a fat object based on available optional dependencies there, or if it authenticates against mod-login for a token and then makes subsequent calls to new permission-less _self endpoints to fill in user details, permissions, etc.

I can do the front-end work while waiting for the back-end work to be completed, regardless of which approach we choose, but I do need to know which approach we will choose. I'm happy to facilitate a discussion and file the necessary Jiras, or even to make an executive decision, but given this will involve a bunch of back-end work I think it would be best to make sure all parties are on-board with the plan. So, how can we move forward on this? Do you think it's a decision for Prokopovych (since they manage mod-users-bl) or core-platform (since they manage many other modules related to auth-n) or a collection of folks since this is an architectural decision that crosses team and module boundaries?

Comment by Zak Burke [ 18/Jul/22 ]

In chatting with a few folks, I'm inclined to implement this by leveraging optional dependencies on the back-end in mod-users-bl. A lot of the UI code will be the same either way and I'll start with that work. If folks object, please let me know.

Comment by Khalilah Gambrell [ 27/Jul/22 ]

Blocked until a meeting the week of Aug 1

Comment by Marc Johnson [ 28/Jul/22 ]

Khalilah Gambrell

Blocked until a meeting the week of Aug 1

Is this the meeting Craig McNally has arranged due to my feedback?

If so, my feedback does not block the start of the work to make service points etc optional dependencies in mod-users-bl that I think Craig McNally wanted Steve Ellis to start on.

Comment by Steve Ellis [ 28/Jul/22 ]

Marc Johnson and Khalilah Gambrell - FWIW I'm not blocked by the meeting and am working on what needs to change in  mod-usersbl to reduce its dependencies which I'll share in the meeting on Monday or perhaps sooner to give folks a chance to think it over.

Comment by Craig McNally [ 08/Aug/22 ]

Zak Burke is this still blocked?

Comment by Mike Taylor [ 28/Sep/22 ]

As of earlier today, this is no longer blocked and can, I think, be closed.

Generated at Thu Feb 08 23:26:44 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.