[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 |
OverviewThe 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
Starter for 10 Module ListProvided by steve.osguthorpe might be out of date
|
| 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 And if that's not possible extend the set to include: mod-configuration 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:
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 ] |
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:
|
| 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:
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 ] |
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. |