[STCOR-835] refactor getUserTenantsPermissions to leverage roles instead of permissions

[ryandberger]

• Conditionally use /users-keycloak/_self endpoint when users-keycloak interface is present.
• Fulfills STCOR-835.

[github-actions]

Jest Unit Test Results

  1 files  ±0   56 suites  ±0   1m 34s ⏱️ ±0s
339 tests ±0  339 ✅ ±0  0 💤 ±0  0 ❌ ±0 
343 runs  ±0  343 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 2e9829d. ± Comparison against base commit cc8ef65.

♻️ This comment has been updated with latest results.

[github-actions]

Bigtest Unit Test Results

192 tests  ±0   187 ✅ ±0   7s ⏱️ -1s
  1 suites ±0     5 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 2e9829d. ± Comparison against base commit cc8ef65.

This pull request removes 5 and adds 3 tests. Note that renamed tests count towards both.

      equal to check email label in english translation
      equal to check email precautions label in english translation
      equal to sent email precautions label in english translation
Chrome_129_0_0_0_(Linux_x86_64).Forgot username/password status test check email status page tests ‑ Forgot username/password status test check email status page tests should have the header with an appropriate text content
Chrome_129_0_0_0_(Linux_x86_64).Forgot username/password status test check email status page tests ‑ Forgot username/password status test check email status page tests should have the paragraph with an appropriate text content

Chrome_129_0_0_0_(Linux_x86_64).Forgot username/password status test check email status page tests ‑ Forgot username/password status test check email status page tests should have the header with an appropriate text content
      equal to check email label in english translation
Chrome_129_0_0_0_(Linux_x86_64).Forgot username/password status test check email status page tests ‑ Forgot username/password status test check email status page tests should have the paragraph with an appropriate text content
      equal to check email precautions label in english translation
Chrome_129_0_0_0_(Linux_x86_64).Forgot username/password status test check email status page tests ‑ Forgot username/password status test check email status page tests should have the paragraph with an appropriate text content
      equal to sent email precautions label in english translation

♻️ This comment has been updated with latest results.

[zburke]

I'm uncertain about this in light of the corresponding work @aidynoJ just did for UIU-3102 in PR 2752 to eliminate dependencies on the users-keycloak interface. I'm also confused about the directions given on this ticket. The conditional checks for the presence of roles but the endpoint (/users-keycloak/_self) comes from users-keycloak, so something seems amiss.

Finally, on the non-Eureka side, we should use /bl-users/_self instead of /perms/users/${id}/permissions since the former is universally accessible to any authenticated user but the latter requires specific permissions. If you don't want to do that clean up here I understand. Please file a new bug on UIU and have a chat with the ECS team who originally implemented this function since it was done incorrectly.

[ryandberger]

I'm uncertain about this in light of the corresponding work @aidynoJ just did for UIU-3102 in PR 2752 to eliminate dependencies on the users-keycloak interface. I'm also confused about the directions given on this ticket. The conditional checks for the presence of roles but the endpoint (/users-keycloak/_self) comes from users-keycloak, so something seems amiss.

Finally, on the non-Eureka side, we should use /bl-users/_self instead of /perms/users/${id}/permissions since the former is universally accessible to any authenticated user but the latter requires specific permissions. If you don't want to do that clean up here I understand. Please file a new bug on UIU and have a chat with the ECS team who originally implemented this function since it was done incorrectly.

Seems like based on folio-org/ui-users#2752, both Eureka and non-Eureka can call /bl-users/_self. Is that correct?

[aidynoJ]

I'm uncertain about this in light of the corresponding work @aidynoJ just did for UIU-3102 in PR 2752 to eliminate dependencies on the users-keycloak interface. I'm also confused about the directions given on this ticket. The conditional checks for the presence of roles but the endpoint (/users-keycloak/_self) comes from users-keycloak, so something seems amiss.

Finally, on the non-Eureka side, we should use /bl-users/_self instead of /perms/users/${id}/permissions since the former is universally accessible to any authenticated user but the latter requires specific permissions. If you don't want to do that clean up here I understand. Please file a new bug on UIU and have a chat with the ECS team who originally implemented this function since it was done incorrectly.

Seems like based on folio-org/ui-users#2752, both Eureka and non-Eureka can call /bl-users/_self. Is that correct?

That was the requirements for UIU-3192

[aidynoJ]

I might be wrong. But based on https://folio-org.atlassian.net/browse/MODUSERSKC-30 and Bridging the gap between Users in the system and Users of the system we no longer need to create keycloak record directly. We can create them by assigning users to role and vice versa.

[ryandberger]

I might be wrong. But based on https://folio-org.atlassian.net/browse/MODUSERSKC-30 and Bridging the gap between Users in the system and Users of the system we no longer need to create keycloak record directly. We can create them by assigning users to role and vice versa.

In this case, the endpoint is just being used to retrieve permissions a user has with tenants within a consortium. There is no create actions taking place here.

[aidynoJ]

I might be wrong. But based on https://folio-org.atlassian.net/browse/MODUSERSKC-30 and Bridging the gap between Users in the system and Users of the system we no longer need to create keycloak record directly. We can create them by assigning users to role and vice versa.

In this case, the endpoint is just being used to retrieve permissions a user has with tenants within a consortium. There is no create actions taking place here.

I meant that probably it is related, now when we create user, the user is not created in keycloak and calling mod-roles-keycloak _self might cause an issue

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
83.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud