STCOR-1027 Use GET mod-settings /locale API to get tenant language & locale settings

[BogdanDenis]

Description

Context: With the Trillium release, Language & locale settings were moved from mod-configuration to the /locale API of mod-settings. These settings are tenant level (a user can also set user preference for language at some other API).

• Front-end modules that use these tenant settings need to call the /locale endpoint to get these settings.
• Update required interfaces and required permissions from mod-configuration to mod-settings.
• If this work is not completed in Trillium then any workflows using locale settings will not work as expected.

Also this work is required for mod-configuration deprecation.

Approach

• Fetch tenant locale settings from /locale API.
• Removed calls to fetch tenant locale settings from /settings/entries and /configurations/entries
• Removed calls to fetch user locale settings from /configurations/entries
• User locale settings are now fetched from /settings/entries

Issues

STCOR-1027

Related PRs

folio-org/ui-tenant-settings#486

[github-actions]

Bigtest Unit Test Results

  1 files  ±  0    1 suites  ±0   0s ⏱️ -6s
  2 tests  - 148    2 ✅  - 147  0 💤  - 1  0 ❌ ±0 
152 runs  +  2  152 ✅ +  3  0 💤  - 1  0 ❌ ±0 

Results for commit 856a793. ± Comparison against base commit 5887b96.

This pull request removes 152 and adds 2 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_144_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_144_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_144_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_144_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_144_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_144_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_144_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_144_0_0_0_(Linux_x86_64).loadRemoteComponent ‑ loadRemoteComponent should handle errors when loading the remote script
Chrome_144_0_0_0_(Linux_x86_64).loadRemoteComponent ‑ loadRemoteComponent should inject the script tag with the requested src attribute

♻️ This comment has been updated with latest results.

[github-actions]

Jest Unit Test Results

  1 files  ± 0   84 suites  +1   1m 42s ⏱️ ±0s
516 tests +11  516 ✅ +11  0 💤 ±0  0 ❌ ±0 
522 runs  +11  522 ✅ +11  0 💤 ±0  0 ❌ ±0 

Results for commit 856a793. ± Comparison against base commit 5887b96.

This pull request removes 9 and adds 20 tests. Note that renamed tests count towards both.

getLocale dispatches setTimezone, setCurrency ‑ getLocale dispatches setTimezone, setCurrency
getUserLocale dispatches setTimezone, setCurrency ‑ getUserLocale dispatches setTimezone, setCurrency
loadResources when there are permissions to read mod-settings and mod-configuration when the user and tenant locale settings are present in mod-settings should fetch the tenant and user locale settings from mod-settings ‑ loadResources when there are permissions to read mod-settings and mod-configuration when the user and tenant locale settings are present in mod-settings should fetch the tenant and user locale settings from mod-settings
loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should apply locale settings from mod-configuration ‑ loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should apply locale settings from mod-configuration
loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should fetch the tenant and user locale settings from mod-settings and mod-configuration ‑ loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should fetch the tenant and user locale settings from mod-settings and mod-configuration
loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should retrieve tenant-locale, user-locale, plugins, and bindings from configurations ‑ loadResources when there are permissions to read mod-settings and mod-configuration when the user or tenant locale settings are not present in mod-settings should retrieve tenant-locale, user-locale, plugins, and bindings from configurations
loadResources when there is permission to only read mod-configuration should apply locale settings ‑ loadResources when there is permission to only read mod-configuration should apply locale settings
loadResources when there is permission to only read mod-configuration should fetch the tenant and user locale settings from mod-configuration ‑ loadResources when there is permission to only read mod-configuration should fetch the tenant and user locale settings from mod-configuration
loadResources when there is permission to only read mod-configuration should retrieve tenant-locale, user-locale, plugins, and bindings from configurations ‑ loadResources when there is permission to only read mod-configuration should retrieve tenant-locale, user-locale, plugins, and bindings from configurations

EntitlementLoader children rendering renders children when modules are available ‑ EntitlementLoader children rendering renders children when modules are available
EntitlementLoader loadModuleAssets converts kebab-case locale to snake_case for translations ‑ EntitlementLoader loadModuleAssets converts kebab-case locale to snake_case for translations
EntitlementLoader loadModuleAssets handles array translation values with messageFormatPattern ‑ EntitlementLoader loadModuleAssets handles array translation values with messageFormatPattern
EntitlementLoader loadModuleAssets handles translation fetch errors ‑ EntitlementLoader loadModuleAssets handles translation fetch errors
EntitlementLoader loadModuleAssets loadEntitlement calls fetch ‑ EntitlementLoader loadModuleAssets loadEntitlement calls fetch
EntitlementLoader loadModuleAssets loads translations for a module ‑ EntitlementLoader loadModuleAssets loads translations for a module
EntitlementLoader preloadModules assigns getModule function to loaded modules ‑ EntitlementLoader preloadModules assigns getModule function to loaded modules
EntitlementLoader preloadModules handles loading errors gracefully ‑ EntitlementLoader preloadModules handles loading errors gracefully
EntitlementLoader preloadModules loads remote components and builds module structure ‑ EntitlementLoader preloadModules loads remote components and builds module structure
EntitlementLoader when discoveryUrl is configured fetches the registry and loads modules dynamically ‑ EntitlementLoader when discoveryUrl is configured fetches the registry and loads modules dynamically
…

♻️ This comment has been updated with latest results.

[zburke]

@BogdanDenis, I don't think we should remove the calls to /configuration/entries as described under "Approach". That feels like a breaking change, even if we're not changing the okapiInterfaces at all. Do you see it this way?

I realize these loginServices functions are a rat's nest. I think they are all internal to stripes-core though (they are exported here, but not exported publicly from the package from the root index.js, so if we need to do a little more refactoring in order to pass in stripes so we can access stripes.hasInterface(), let's do that.

And if I've misunderstood what is happening here, my apologies. A lot of code is moving around and it's a bit hard to keep track of.

[BogdanDenis]

@zburke I agree that it's a breaking change - I should have marked it as such.
locale interface was already listed in optionalOkapiInterfaces, so I didn't have to add it here.

But leaving the calls to /configurations/entries to fetch tenant locale is pointless IMO.
Starting with Trillium, locale workflows will be using the new locale API, and if we're switching to a different API to store tenant locale, and all other UI and BE modules will be using that API too - then we don't need these backup calls to a deprecated endpoint.

But it really is a bit of a mess... we used /configurations/entries to store tenant and user locale, then 8 months ago we switched to /settings/entries for both and still kept calls to /configurations/entries as backup for some reason. And now we're switching to /locale BUT only for tenant locale. User locale settings will still use /settings/entries.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[zburke]

@BogdanDenis, 100% it's a mess, no debate there. TLDR, locale data turned out to be the tip of an iceberg of permissions issues for data stored at /settings/entries.

I understand that keeping the /configurations/entries calls around feels pointless, but we pledged not to implement breaking changes in Trillium** and I think we should honor that. This breaking change is only in the interfaces stripes-core consumes, not in those it provides, which I think would make this under-the-hood break especially hard to swallow. I'm willing to have the discussion if you want to bring this to Slack#stripes-architecture and see what other folks think, but you know where I stand on this :)

** Sunflower was a major release, and we anticipate Umbrellaleaf will be too, if we can get our act together and wrap up React v19 compatibility work. If Trillium becomes a major release, that puts pressure on us to avoid breaks in Umbrellaleaf, delaying that update even further into the future. Of course, it's possible to provide React v18 and v19 compatibility simultaneously (we avoid deprecated features from v18 AND we avoid new feature from v19) but this is more work with less benefit.

So, yeah, it's a mess.