[FOLIO-683] Decide where to define VHLPs and how to get them into the permissions database Created: 13/Jun/17  Updated: 12/Nov/18  Resolved: 19/Jun/17

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

Type: Task Priority: P3
Reporter: Mike Taylor Assignee: Mike Taylor
Resolution: Done Votes: 0
Labels: sprint16, team1
Remaining Estimate: Not Specified
Time Spent: 7 hours, 45 minutes
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-636 Update stripes-docker role in folio-a... Closed
Relates
relates to STRIPES-435 Modify Names of Logical Permissions Closed
relates to STCOR-5 Tool to generate UI modules' ModuleDe... Closed
Sprint:

 Description   

We have a long-running and ill-defined problem with how and where to define Very High Level Permissions (VHLPs) such as "Can edit user profile". Comments below discuss the present plan, and raise some concerns about it.



 Comments   
Comment by Mike Taylor [ 14/Jun/17 ]

I added the permissions from the users-bl module's ModuleDescriptor.json, ready to extract into the ui-users autogenerated descriptor file (see STCOR-5 Closed ). But then in discussion with Jason, I found that he has rather different ideas. We need to get together with Jakub and Heikki, and thrash this out.

Comment by Mike Taylor [ 14/Jun/17 ]

I speculatively re-added two high-level permissions. At this stage I am doing it so that we have something concrete to discuss tomorrow, and so I can work on the translation tool of STCOR-5 Closed .

See https://github.com/folio-org/ui-users/commit/d05054fc3ea95565b787711f8fd57457cc93dc46

Comment by Mike Taylor [ 19/Jun/17 ]

Jason, Jakub and I (with some input from Heikki) had a long but inconclusive discussion on Thursday about how to progress the broader issues. I will describe the outcome in a separate new issue, a higher level overview of what we want to do here.

In the mean time, this specific issue is now complete: I added two top-level permissions as noted above (users-bl.view and users-bl.edit), which suffice as a proof of concept for one way of handling such issues. Meanwhile, I made a tool to generate UI modules' ModuleDescriptor.json from package.json (see STCOR-5 Closed ) so that we have a way of surfacing those permissions in a way that Okapi can use. So I am closing this one as complete.

Comment by Mike Taylor [ 19/Jun/17 ]

On reflection, the issue that this one blocks ( FOLIO-636 Closed ) is a perfectly good place to discuss Jason's reservations with our approach, so I will comment there rather than creating a new issue for discussion.

Comment by Jakub Skoczen [ 19/Jun/17 ]

Mike Taylor I'd rather discuss where to keep Permission Sets here, not on FOLIO-636 Closed . We are going forward with FOLIO-636 Closed no matter where the permsets live, it's a very specific issue.

Comment by Mike Taylor [ 19/Jun/17 ]

OK. I'd started writing my comment, but not submitted it

I will make a new issue, though, rather than keeping this one on life support. The goal of this was a do a specific thing, and that thing is done.

Comment by Jakub Skoczen [ 19/Jun/17 ]

I've filed a subtask for the specific thing you've done.

Comment by Mike Taylor [ 19/Jun/17 ]

All right. The discussion will go here after all, then.
sigh

Comment by Mike Taylor [ 19/Jun/17 ]

Jason, Jakub and I (with some input from Heikki) had a long but inconclusive discussion on Thursday about how to achieve the goal that this issue in part describes – that is, where to define Very High Level Permissions (VHLPs) and how to get them into the database so that an administrative user can assign them to users.

The present plan (partially implemented in UIU-94 Closed ) is as follows:

  • VHLPs are considered part of the interface of a UI module, since they describe actions that are part of the UI.
  • Accordingly, they are defined in the metadata for the relevant UI module.
  • Specifically, because UI modules are NPM modules and NPM modules are described by a `package.json` file, the permissions are now included in that package file.
  • A FOLIO `ModuleDescriptor.json` is auto-generated from the package file, using the new package2md.js tool in stripes-core ( STCOR-5 Closed ). (You can do this using `yarn mkmd` in the ui-users area.)
  • Somehow – the details are not not yet clear, at least not to me – some part of the tenant-build process inserts the generated ModuleDescriptor.json into Okapi.
  • Okapi's handling of this descriptor includes adding the permissions it defined into the permissions database.
  • They are therefore available for administrators to assign to users.

I would be happier with this if I understand (A) the "somehow" part above, and (B) the lifespan of permissions created by inserting module-descriptors into Okapi. Do the permissions disappear when the module-descriptor is removed? (Can that even happen?) What happens if the same module-descriptor is inserted multiple times.

But these are questions of detail. Jason had some more philosophical issues here, which I will try to summarise in the next comment.

Comment by Mike Taylor [ 19/Jun/17 ]

If I rightly understand Jason's concerns, they are twofold.

1. Philosophical. He feels that the module-descriptor for a UI module should contain information about the Okapi service for the UI module – which it does, at the moment, in the okapiInterfaces section. But VHLPs are the opposite: they are information about the UI module for the Okpai service.

2. Practical. If we use the scheme outlined above, then a UI module author who wants to run against a particular FOLIO server has to somehow arrange to have that server consume its module descriptor. That raises the bar for module developers, who we would like to be free to make whatever they want on top of services provided by the server. In an extreme case, it might even mean a UI developer needing to make their own FOLIO server instance so they have permission to do this module-descriptor insertion.

I am sympathetic to both of these concerns.

Comment by Mike Taylor [ 19/Jun/17 ]

I have two things to say in rebuttal of Jason's position.

1. If not in the ui-module's metadata, where should the VHLPs live? Jakub pointed out that if Jason thinks there is a better approach, he has not yet really told us what it is. Since we need to implement something, we really need a concrete counter-proposal if we're not to do something along the lines I described above.

2. If I rightly understood Jason's permission, it seems that whatever alternative outcome he wants, it entails the VHLPs being defined on the server side – for example, ui-users' permissions in mod-users-bl. This seems conceptually wrong to me. The set of permissions required to do a UI-level operation are really part of the UI definition.

One could imagine one users UI module where "Can view user profile" entails the ability to read a user's permissions – so that it would need to include the low-level permission perms.users.get; and another alternative users UI module, created under the influence of a different UX team, where permissions management is considered separate from user management, and where the not-really-equivalent "Can view user profile" permission would therefore not include perms.users.get. In such a scenario, it seems it me it would be Just Plain Wrong for the mod-users-bl module to unilaterally define what "Can view user profile" means.

So I think I am close to persuading myself that Jason's concerns should not be deal-breakers here. I do share his concern about the practical matter that what we propose here to some degree raises the bar for module developers – but actually, it shouldn't be a deal-breaker, since VHLPs are not a mandatory part of what the UI module need to run, they are just an administrative convenience. If a UI developer really needs a VHLP, she can add it as a permission-set.

Comment by Mike Taylor [ 19/Jun/17 ]

I've now said all I have to say about this, and I'd welcome others' insights.

Comment by Heikki Levanto [ 19/Jun/17 ]

Do I understand right that one ModuleDescritpor is generated when a bundle is built for a tenant, and it covers all the stuff included in that bundle? That does not sound right to me, one descriptor describing a whole bundle of UI modules. That would also mean that the MD is specific to this one tenant, which is kind of backwards from the way things work in Okapi.

I understood that we once decided that when a new UI module is enabled for a tenant - in Okapi - that should trigger the building of a new bundle that includes that module. Okapi will enforce that the dependencies of that module are satisfied. Maybe that is not the case any more?

In any case, if something changes, and you create a new ModuleDescriptor, you must give it a new, unique ID, with a version number that is properly incremented. If you create a MD with the same ID and different contents, things will break!

Comment by Mike Taylor [ 19/Jun/17 ]

Ah, no, sorry, I didn't explain this clearly. The bundle contains n UI modules, and each of them comes with its own ModuleDescriptor,json.

The script at https://github.com/folio-org/stripes-core/blob/master/util/package2md.js generates the module-descriptor. As you can see, it generates an id based on both the name and the version number of the NPM module – so we should get the outcome you want, that the IDs in the descriptors for different versions are different.

Comment by Heikki Levanto [ 19/Jun/17 ]

Ah, that makes more sense.

Comment by Jason Skomorowski [ 19/Jun/17 ]

Luckily I'm actually here-ish – My actual schedule is that I am at a conference Jun 20-22nd and away Jun 27th - July 5th and so get this chance to be part of a discussion where it's sort of like I'd died. You did sort of summarise one of my points but I think missed the other. I'll give it a shot:

1. The back end needs to be aware of the UI consuming it. Currently it does not and you can spin up an utterly custom UI and use it against a very locked down Okapi and it's fine. So this decision, right here, would be to take away the option of self-hosting the front end (which is way easier and needs less infrastructure) while using the SaaS for the back-end making FOLIO an either all-SaaS or all-self-hosted proposition just so that we can get permission sets that map closely to the UI. Meh. To me, that doesn't seem worth the price. And as you say, it complicates development.

2. All the permissions have to be redone if you want to change UIs / use another UI. If we make permissions this close to the UI, the work the institution does to configure the permissions for their userbase is now utterly coupled to the UI and they'll need to do it over again if they choose a different one. This adds friction to choice and experimentation, seems contrary to the spirit of FOLIO. Even not changing the whole UI but merely swapping out one module for another implementing the same interface would require reassignment of the related permissions. And how would using multiple UIs within the same institution work? With the same set of users?

And I did propose an alternative: The Kinda High Level Permissions (KHLP) and Extremely High Level Permissions (EHLP).

Currently we have overly-granular permissions that are at an operational level and include implementation details transparent to actual usage and therefore want something higher level. I suggested KHLP be at the business logic module level and provide as granular of permissions as still make conceptual sense that someone might ever want to change them separately (independent of UI, just abstractly the kinds of things we want someone to be able to do or not within the system).

Additionally, we can offer EHLPs as modules just consisting of some permission set defaults to be used as-is or as a starting point to define some specific to an institution after minor tweaks to their KHLPs. There can be multiple levels of these, some like "Circulation Librarian" might be even higher level than others like "Administer Users".

Comment by Jason Skomorowski [ 19/Jun/17 ]

As for philosophical I do very much like the notion that UIs are presentational only and the business logic lives on the server. Which I thought we were using as a constraint in our design? The idea of which users can perform which operations, and, indeed, which operations are possible within the system seem to me very much like business logic?

Also, client-defined permissions leaves the door open for client-side only permissions and those would be a total lie---the client is all running in the browser and therefore can't enforce anything. All a pure client-side permission can be is aesthetic and such things are best kept alongside other client configuration and separate from actual permissions.

Comment by Mike Taylor [ 19/Jun/17 ]

The back end needs to be aware of the UI consuming it.

I don't see how that follows at all. What will go wrong if the UI can't find a way to get its module-descriptor across to Okapi? Only this: administrators using it will not be able to use the VLHPs it defines. Hardly crippling to developers.

2. All the permissions have to be redone if you want to change UIs / use another UI.

I don't see that, either. The only permissions that you would lose in moving from one UI to another are the ones that are properly tied to the first UI because they encapsulate something about how that UI divides up the tasks (e.g. my earlier example about UIs that do and do not include permission-viewing in "Can view users".) And that's not a bug, it's a feature. Meanwhile, the other 99% of the permissions will still be down in the server, because they describe server operations rather than UI screens.

How would using multiple UIs within the same institution work? With the same set of users?

Again, I am not seeing the problem. Where the UIs present different functionality. they will also present different VHLPs. That's simply a matter of honest modelling.

Comment by Jason Skomorowski [ 19/Jun/17 ]

If you stop using the old UI and have used its permission sets to configure all your users ...it'd be nice if you could turn off the UI but keep the permission sets. And only tweak the ones you need to adapt to the new UI you're switching to.

By definition, everything a permission actually can enforce exists on the server-side. It feels like so too should the abstractions.

I don't really think I'm proposing much that is different, mainly building the KHLPs to make EHLPs easier to build and fine-tune plus having the EHLPs live as their own Okapi modules so they can transcend UIs. You can still have some that really only fully make sense in the context of a particular UI, but they can stick around after you turn off that UI while you transition to the next thing.

At any rate, I've said my piece. I'm not especially affected by the ramifications of all this so I'm fine to leave it up to those who are.

Comment by Mike Taylor [ 20/Jun/17 ]

If you stop using the old UI and have used its permission sets to configure all your users ...it'd be nice if you could turn off the UI but keep the permission sets. And only tweak the ones you need to adapt to the new UI you're switching to.

I think that is exactly what we're talking about – tweaking the ones that are specific to the particular UI.

And remember – just because a permission is defined on the client side, doesn't mean it's enforced there. The client-side VHLPs we're talking about here are only (or at least primarily_ aggregations of real, solid, server-side permissions that are enforced by Okapi/mod-auth.

I think your important practical insight here is that we can define permissions in "shell modules" with no content but the module descriptor. (In fact, we can do that from the client side or the server side.) I think thats a potentially important refinement; but not one that requires additional development.

So my conclusion is that we can proceed with the scheme more or less as outlined above, but with the refinement that we may define permissions in any of a variety of places:

  • In a regular UI module such as ui-users
  • In a dedicated perms-only module on the client side, e.g. ui-users-perms
  • In a dedicated perms-only module on the server side, e.g. mod-users-perms
  • In a regular server-side module such as mod-users-bl or mod-users

We've outlined a mechanism that can handle all of these, and can now leave it up to others to decide the policy that will be built on that mechanism.

Comment by Mike Taylor [ 20/Jun/17 ]

And with that, I declare this issue complete.

Comment by Mike Taylor [ 20/Jun/17 ]

Moved from FOLIO-683 Closed when to FOLIO-683 Closed , since it ended up being a whole-FOLIO-system issue rather than something to do with the ui-users module.

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