We faced an issue related to folio permission renaming and its support in Okapi + mod-permissions.
We conducted the following spike in order to assess the permissions' renaming transparency for the end users.

1. Create a fresh environment with FOLIO, using old permissions.

2. Create a user and assign permissions to that user.

   1. There should be a permission set containing permission from the backend module that will be renamed.

   2. There should be a permission set containing another permission set that will be renamed

   3. There should be a permission set that will be renamed

3. Create snapshots for tables in the mod-permissions schema (permissions, permissions_users);

4. Save a response from the "_self" request for comparison.

5. Deploy back-end modules from the branches with the renamed permissions. Do not enable modules for a tenant (Jenkins job).

6. Merge UI changes into master branches. The UI module descriptors will be generated.

7. Manually register generated UI module descriptors in Okapi.

8. Manually enable new versions of modules for a tenant.

9. Check user permission and availability of UI controls.

10. Check the response from the "_self" request and compare it to the previous one.

11. Compare the content of the tables in the mod-permissions schema.

The result is disappointing.Okapi does not support the correct migration of UI permissions.
Furthermore, after such a migration, the set of permissions for each individual user changes randomly. Permissions that have been renamed disappear from the list of those assigned to the user.We reproduced this in two different environments.

For the sake of simplicity, we selected two modules ui-oai-pmh and mod-oai-pmh.
We created a user and assigned the following permissions:
["ui-oai-pmh.view", "ui-oai-pmh.edit", "ui-oai-pmh.logs"]

Then we did the following permission renaming:

• on the back-end (this is just for testing purposes, there's no logic behind this renaming)
  "oai-pmh.sets.item.put" -> "oai-pmh.settings.item.put"
  "oai-pmh.request-metadata.logs.item.get" -> "oai-pmh.metadata.logs.item.get"

• on the front-end
  "ui-oai-pmh.view" -> "ui-oai-pmh.settings.view"
  "ui-oai-pmh.edit" -> "ui-oai-pmh.settings.edit"
  "ui-oai-pmh.logs" -> "ui-oai-pmh.settings.logs.view"

After the modules' updates the set of the permissions assigned to the user was:
["ui-oai-pmh.settings.logs.view"]

We did the same on another env, and as a result, we got this set of permissions assigned to the user after modules' updates:
["ui-oai-pmh.settings.edit"]

The expected result is that the user should have the following set of permissions assigned:
["ui-oai-pmh.settings.view", “ui-oai-pmh.settings.edit", “ui-oai-pmh.settings.logs.view"]

We did testing in Rancher Dev env and on the sprint testing Rancher env.
We used artifacts built from the master branches to create environments for all FOLIO modules (SNAPSHOT versions)

Cause

A simplified version of the code is this:

If there are multiple permission replacements for one user the GenericCompositeFuture.all allows Vert.x to run them in parallel.

Therefore all lookupPermsUsersById SELECTs read the old permission set of the user.

Due to GenericCompositeFuture.all all SELECTs have completed when the UPDATEs start.

Each update adds only one new permission, and each update overwrites the added permission of the previous updates.

The complete permission migration runs on a single transaction to allow for roll-back in case of failure. Therefore PostgreSQL doesn’t reject the UPDATE based on an outdated SELECT.

Solution

Replace GenericCompositeFuture.all with sequential future.compose. Do this also for other GenericCompositeFuture.all in the TenantPermsAPI.

This doesn’t cause any performance issue because all SQL queries run on a single transaction and therefore cannot run in parallel, even when using GenericCompositeFuture.all.

Consider merging the SELECT and the following UPDATE into a single UPDATE when it makes the code easier.