UITEN-278 - create reading room from tenant settings

[Terala-Priyanka]

Purpose

https://folio-org.atlassian.net/browse/UITEN-278 - Reading Room Access (settings): Create new reading room

Note

The base branch for this PR is not master. Volaris will merge this feature branch for ui-tenant-settings module at a little later point in time. Also, base branch is always maintained equivalent to master.

Screencast

chrome_iC8SY6pYmJ.mp4

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 Statistics

    1 files  ±0  28 suites  ±0   2m 17s ⏱️ +4s
100 tests +3  88 ✔️ +3  12 💤 ±0  0 ❌ ±0 
102 runs  +3  90 ✔️ +3  12 💤 ±0  0 ❌ ±0 

Results for commit e623a35. ± Comparison against base commit 8db6552.

♻️ This comment has been updated with latest results.

[github-actions]

BigTest Unit Test Statistics

0 tests  ±0   0 ✔️ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit e623a35. ± Comparison against base commit 8db6552.

♻️ This comment has been updated with latest results.

[vashjs]

Could you please use reduce, I know it's the same but as for me looks more clear

const options = servicePoints.reduce((acc, s) => {
  if (!sps.includes(s.id) || s.name === 'None') {
    acc.push({ value: s.id, label: s.name });
  }
  return acc;
}, []);

[vashjs]

What about to handle it with base array methods to avoid this tracking of closures?

Maybe like this:

const sps = rrs.reduce((acc, rr) => {
  acc.push(...(rr.servicePoints || []).map((s) => s.value));

  return [...new Set(acc)];
}, []);

Or maybe

const sps = rrs
  .map((rr) => rr.servicePoints || [])
  .map((s) => s.value)
  .flat();

const uniqSps = [...new Set(spss)];

Note: I didn't check it live with your code, just as an example

[Terala-Priyanka]

Quickly check, but it seems not equivalent. I prefer to retain my implementation.

[vashjs]

Is there is any reason use name function instead of just arrow? Looks like it calls by key and this name is visible only here.

[Terala-Priyanka]

updated to anonymous arrow functions

[vashjs]

Items errors looks like redundant, could you please just change to
return validateItem(item, items) || {}

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarCloud