STCOR-905: based on 'users-keycloak' interface use bl-users or users-keycloak for _self endpoint in useUserTenantPermissions

[aidynoJ]

Purpose
STCOR-905 - based on 'users-keycloak' interface use bl-users or users-keycloak for _self endpoint in useUserTenantPermissions #1556

Approach
Remove redundant hooks and make changes in useUserTenantPermissions

[github-actions]

Bigtest Unit Test Results

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

Results for commit c9fb762. ± Comparison against base commit 921f0ab.

This pull request removes 194 and adds 192 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_130_0_0_0_(Linux_x86_64).AppIcon Passing a string to the tag-prop ‑ AppIcon Passing a string to the tag-prop Should render an AppIcon with a HTML tag of "div"
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Passing a string using the children-prop ‑ AppIcon Passing a string using the children-prop Should render an AppIcon with a label
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using Stripes-context ‑ AppIcon Rendering an AppIcon using Stripes-context Should render an <img>
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using Stripes-context ‑ AppIcon Rendering an AppIcon using Stripes-context Should render an img with an alt-attribute
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render an <img>
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render an img with an alt-attribute
Chrome_130_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render with a className of "My className"
…

Chrome_131_0_0_0_(Linux_x86_64).AppIcon Passing a string to the tag-prop ‑ AppIcon Passing a string to the tag-prop Should render an AppIcon with a HTML tag of "div"
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Passing a string using the children-prop ‑ AppIcon Passing a string using the children-prop Should render an AppIcon with a label
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using Stripes-context ‑ AppIcon Rendering an AppIcon using Stripes-context Should render an <img>
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using Stripes-context ‑ AppIcon Rendering an AppIcon using Stripes-context Should render an img with an alt-attribute
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render an <img>
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render an img with an alt-attribute
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Rendering an AppIcon using an icon-object ‑ AppIcon Rendering an AppIcon using an icon-object Should render with a className of "My className"
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Size tests Passing a size of "large" ‑ AppIcon Size tests Passing a size of "large" Should render an icon into a large-sized container
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Size tests Passing a size of "medium" ‑ AppIcon Size tests Passing a size of "medium" Should render an icon into a medium-sized container
Chrome_131_0_0_0_(Linux_x86_64).AppIcon Size tests Passing a size of "small" ‑ AppIcon Size tests Passing a size of "small" Should render an icon into a small-sized container
…

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

Chrome_130_0_0_0_(Linux_x86_64).PasswordValidationField with an invalid password ‑ PasswordValidationField with an invalid password shows a validation error
Chrome_130_0_0_0_(Linux_x86_64).useCustomFields hook requests for existing custom fields ‑ useCustomFields hook requests for existing custom fields should have custom fields
Chrome_130_0_0_0_(Linux_x86_64).useCustomFields hook requests for non-existing custom fields ‑ useCustomFields hook requests for non-existing custom fields should have error
Chrome_130_0_0_0_(Linux_x86_64).useCustomFields hook requests for version-compatible custom fields ‑ useCustomFields hook requests for version-compatible custom fields should have custom fields
Chrome_130_0_0_0_(Linux_x86_64).useCustomFields hook requests for version-incompatible custom fields ‑ useCustomFields hook requests for version-incompatible custom fields should have error

Chrome_131_0_0_0_(Linux_x86_64).PasswordValidationField with an invalid password ‑ PasswordValidationField with an invalid password shows a validation error
Chrome_131_0_0_0_(Linux_x86_64).useCustomFields hook requests for existing custom fields ‑ useCustomFields hook requests for existing custom fields should have custom fields
Chrome_131_0_0_0_(Linux_x86_64).useCustomFields hook requests for non-existing custom fields ‑ useCustomFields hook requests for non-existing custom fields should have error
Chrome_131_0_0_0_(Linux_x86_64).useCustomFields hook requests for version-compatible custom fields ‑ useCustomFields hook requests for version-compatible custom fields should have custom fields
Chrome_131_0_0_0_(Linux_x86_64).useCustomFields hook requests for version-incompatible custom fields ‑ useCustomFields hook requests for version-incompatible custom fields should have error

♻️ This comment has been updated with latest results.

[github-actions]

Jest Unit Test Results

  1 files  ±0   55 suites   - 2   1m 31s ⏱️ -1s
348 tests  - 3  348 ✅  - 3  0 💤 ±0  0 ❌ ±0 
351 runs   - 3  351 ✅  - 3  0 💤 ±0  0 ❌ ±0 

Results for commit c9fb762. ± Comparison against base commit 921f0ab.

This pull request removes 4 and adds 1 tests. Note that renamed tests count towards both.

useUserSelfTenantPermissions should fetch user permissions for specified tenant ‑ useUserSelfTenantPermissions should fetch user permissions for specified tenant
useUserTenantPermissionNames should fetch user permissions for specified tenant ‑ useUserTenantPermissionNames should fetch user permissions for specified tenant
useUserTenantPermissions should return _self permissions data when "roles" interface is present ‑ useUserTenantPermissions should return _self permissions data when "roles" interface is present
useUserTenantPermissions should return tenant permissions data when "roles" interface is NOT present ‑ useUserTenantPermissions should return tenant permissions data when "roles" interface is NOT present

useUserTenantPermissions should fetch user permissions for specified tenant ‑ useUserTenantPermissions should fetch user permissions for specified tenant

♻️ This comment has been updated with latest results.

[ryandberger]

Is this still a draft PR?

[aidynoJ]

Is this still a draft PR?

Just wanted to change implementation of useUserTenantPermissions.

[ryandberger]

Please fix lint issue.

[zburke]

Code changes look correct to me, but changing the hook's name is a breaking change. If the target is sunflower, that's OK (we know that release will contain breaking changes), but we should do that work in two phases:

1. in stripes-core, export this hook by its old and new names
2. in other repositories, refactor to the new name
3. in stripes-core, remove the export of the old name

That avoids the need to merge PRs here and across the UI repositories at the same moment. If we go that route, how about a shorter name, e.g. useTenantPermissions? Permissions don't exist outside the context of a user, so that part of the name feels redundant.

Alternatively, just leave the name as-is. That allows consumers of this hook (inventory, marc-authorities, quick-marc, and stripes-authority-components) to stay as-is, and ui-users can name its local hook whatever it wants to, even if it overlaps; because it isn't importing from stripes-core there isn't a naming conflict, even if it's confusing.

Also, lint :)

[aidynoJ]

Code changes look correct to me, but changing the hook's name is a breaking change. If the target is sunflower, that's OK (we know that release will contain breaking changes), but we should do that work in two phases:

1. in stripes-core, export this hook by its old and new names
2. in other repositories, refactor to the new name
3. in stripes-core, remove the export of the old name

That avoids the need to merge PRs here and across the UI repositories at the same moment. If we go that route, how about a shorter name, e.g. useTenantPermissions? Permissions don't exist outside the context of a user, so that part of the name feels redundant.

Alternatively, just leave the name as-is. That allows consumers of this hook (inventory, marc-authorities, quick-marc, and stripes-authority-components) to stay as-is, and ui-users can name its local hook whatever it wants to, even if it overlaps; because it isn't importing from stripes-core there isn't a naming conflict, even if it's confusing.

Also, lint :)

Let's choose the easiest way, leave it as is and go further. Developers can decide how to call their local hooks whatever they want :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud