UIREQ-1032, UIREQ-1034, UIREQ-1035 - Request detail view update for Lending, Borrowing and Pickup DCB roles #1120

Terala-Priyanka · 2023-11-09T11:44:39Z

Purpose

Reshare DCB is a feature that allows sharing of assets within consortium.
Folio has primarily 3 roles in this feature - Lending, Borrowing, Pickup

Lending Role

Requested item would be a real item (i.e., an item from inventory).
Requester would be a virtual patron (user type - DCB)

Borrowing Role

Requested item would be a virtual item
Requester would be a real patron

Pickup Role

Requested item would be a virtual item (i.e., an item from inventory).
Requester would be a virtual patron (user type - DCB)
More details of the feature are available at https://wiki.folio.org/display/FOLIJET/DCB+Integration

Approach

Actions menu will display only "cancel request" menu item for all the roles explained above - hence the logic behind this implementation is a check if the request is virtual or item is virtual.
Title and item barcode are available as only text when in case of virtual item.
All virtual items have hardcoded "istanceId" and "holdingsRecordId".
All virtual patrons have their lastname hardcoded to "DcbSystem"

Refs

UIREQ-1032 -[DCB] Request details: Hide all actions except "Cancel Request" in Action menu (Lending library)
UIREQ-1034 - [DCB] Request details: Updates for Action menu and DCB item links (Borrowing library)
UIREQ-1035 - [DCB] Request details: Updates for Action menu and DCB item links (Pickup library)

Screenshots

#1118

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.