Decide where to define VHLPs and how to get them into the permissions database

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

And with that, I declare this issue complete.

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.

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.

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.