UIOR-1501: Migrate custom_fields_label settings from mod-configuration to mod-settings

[elsenhans]

https://folio-org.atlassian.net/browse/UIOR-1501

Purpose

Migrate "custom_fields_label" settings from mod-configuration to mod-settings.
Note: stripes-smart-components supports the scope field.

Description
Porting guide

Approach

• add settings to okapiInterfaces
• add new permissions
  • mod-settings.global.read.ui-orders.custom-fields.manage and
  • mod-settings.global.write.ui-orders.custom-fields.manage
• replace mod-configuration-permissions with mod-settings-permissions
• add scope to ViewCustomFieldsSettings and EditCustomFieldsSettings

Screenshots

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

• I've added appropriate record to the CHANGELOG.md
• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
  • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all they appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

[github-actions]

Jest Unit Test Results

    1 files  ±0    294 suites  ±0   7m 11s ⏱️ +11s
1 001 tests ±0  1 001 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 009 runs  ±0  1 009 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 6932cd4. ± Comparison against base commit e31b952.

♻️ This comment has been updated with latest results.

[zburke]

LGTM, but a few things to note:

• do you still need the configuration okapi-interface or can that be removed now?
• IDK which modules supply the interfaces configuration.prefixes and the others with . in their names but they are not compliant with FOLIO's interface-naming conventions. If these modules are owned by your team, please let your teammates know in order to avoid perpetuating this flaw.

[elsenhans]

Thanks @zburke !

* do you still need the `configuration` okapi-interface or can that be removed now?

The okapi-interface configuration is still used, e.g. here or here.

* IDK which modules supply the interfaces `configuration.prefixes` and the others with `.` 

[...]
If these modules are owned by your team, please let your teammates know in order to avoid perpetuating this flaw.

Seems like mod-orders-storage, mod-finance-storage and mod-organizations-storage are affected.
None of them are managed by our team. I can only offer to create tickets for the corresponding teams.

[zburke]

@elsenhans, I would not create tickets for the non-compliant interface names. They're not gonna change at this point so there's no value in calling attention to it. I only mentioned it from the point of view making sure future names do comply.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud