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 ⏱️ ±0s
  2 tests ±0    2 ✅ ±0  0 💤 ±0  0 ❌ ±0 
152 runs  ±0  152 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 2101663. ± Comparison against base commit 5ab64db.

♻️ This comment has been updated with latest results.

[github-actions]

Jest Unit Test Results

  1 files  ±0   85 suites  ±0   1m 43s ⏱️ ±0s
516 tests  - 9  516 ✅  - 9  0 💤 ±0  0 ❌ ±0 
522 runs   - 9  522 ✅  - 9  0 💤 ±0  0 ❌ ±0 

Results for commit 2101663. ± Comparison against base commit 5ab64db.

This pull request removes 15 and adds 6 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 plugins and bindings ‑ 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 plugins and bindings
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 and tenant locale settings are present in mod-settings should not fetch the tenant and user locale settings from mod-configuration ‑ 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 not fetch the tenant and user locale settings from mod-configuration
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 retrieve tenant-locale and user-locale from settings, plugins and bindings from configurations ‑ 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 retrieve tenant-locale and user-locale from settings, plugins and bindings from configurations
loadResources when there are permissions to read mod-settings and mod-configuration when the user and tenant locale settings are present in mod-settings when both the tenant and user locale settings are present should apply user locale 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 when both the tenant and user locale settings are present should apply user locale 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 when the user locale settings are missing something other than the locale should take it from tenant locale 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 when the user locale settings are missing something other than the locale should take it from tenant locale 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 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 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
…

getLocaleConfigurationsEntries dispatches setTimezone, setCurrency ‑ getLocaleConfigurationsEntries dispatches setTimezone, setCurrency
getUserLocaleConfigurationsEntries dispatches setTimezone, setCurrency ‑ getUserLocaleConfigurationsEntries dispatches setTimezone, setCurrency
loadResources when there are permissions to read locale from locale API should fetch the tenant locale from locale API and user locale settings from mod-settings ‑ loadResources when there are permissions to read locale from locale API should fetch the tenant locale from locale API and user locale settings from mod-settings
loadResources when there are permissions to read locale from locale API should not fetch the tenant and user locale settings from mod-configuration ‑ loadResources when there are permissions to read locale from locale API should not fetch the tenant and user 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 locale API 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 locale API and mod-configuration
loadResources when there is permission to only read mod-configuration should retrieve plugins and bindings from configurations ‑ loadResources when there is permission to only read mod-configuration should retrieve plugins and bindings from configurations

♻️ 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.

[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.

[BogdanDenis]

Hey @zburke I've added calls to configurations/entries and settings/entries back as a fall-back in case locale API is not available. Could you review again please?

Also there is a related PR in ui-tenant-settings - folio-org/ui-tenant-settings#486

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud