UIIN-2452: Enable/disable consortial holdings/item actions based on User permissions

[OleksandrHladchenko1]

Purpose

• In a consortium environment, Instance records may contain holdings from multiple institutions and users from one library may need to evaluate materials that are held by different institutions.
• Users in a central consortial environment should be able to view holdings and items for all member libraries, and depending on permissions, also create and edit holdings and items.
• Users in a local member library should be able to view their own holdings and items first, followed by other consortial member library holdings and items.

Approach

• Added tenantId parameter to useBoundWithHoldings to dynamically change X-Okapi-Tenant header
• In ViewInstance component we fetch all the assigned permissions of all user's tenants using getUserTenantsPermissions function
• In getCurrentTenantPermissions function we get all the assigned permissions of all user's tenants if isUserInConsortiumModed === true otherwise we get just all user's permissions
• Added isViewHoldingsDisabled and isAddItemDisabled props to HoldingButtonsGroup component to disable "View Holdings" and "Add item" buttons when member tenant doesn't have permissions
• Added isBarcodeAsHotlink prop to ItemBarcode component to display barcode as a hotlink or not depends on user's permission
• Added disabled prop to InstanceNewHolding component to disable "Add holding" button if user doesn't have permissions
• In order to update affiliation correctly, replaced Link component with Button and added styles so it behaves as a hotlink
• When user wants to view or create Item/Holding we call updateAffiliation function to switch affiliations if user in on the other member tenant.
• Updated and added unit tests

Refs

UIIN-2452

Screenshots

UIIN-2452.mp4

[github-actions]

Jest Unit Test Statistics

    1 files  ±0  226 suites  ±0   11m 49s ⏱️ +42s
887 tests +7  885 ✔️ +7  2 💤 ±0  0 ❌ ±0 
892 runs  +7  890 ✔️ +7  2 💤 ±0  0 ❌ ±0 

Results for commit e81a420. ± Comparison against base commit 306b510.

♻️ This comment has been updated with latest results.

[BogdanDenis]

Agree with @zburke that potentially validateUser could be used to re-load modules without page reload.
For this though some modifications need to be made to that function, because validateUser takes tenant from current session
https://github.com/folio-org/stripes-core/blob/master/src/loginServices.js#L411

If we're going to continue with page reload - please create a tech debt story and add TODO comments where that reload happens to explain why the reload is needed and link the tech debt story

[zburke]

For this though some modifications need to be made to that function, because validateUser takes tenant from current session

That's true, @BogdanDenis, but that feels like a bug: I expected validateUser() to use the tenant it is given and only pull from the session if no argument is specified, similar to the useOkapiKy implementation in #1348. In fact it's the reverse, using the value pulled from the session by default and only accepting the argument if the session's value is empty. That's puzzling given that createOkapiSession always stores a value for tenant in the session, so I can't come up with any circumstance when validateUser() would use its argument.

@NikitaSedyx, can you provide some context for why it was written this way since it seems deliberate? It would be nice to reuse validateUser() if possible, but if we have different needs (sometimes we want the value from storage to be the default, sometimes we want a specific value to be the default) then we can copy-and-tweak the existing function.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

76.9% Coverage
0.0% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint