Title-Level Requests (Basic)

Current implementation of requests applies requests to items, but users (especially patrons) don't usually care which copy (item) they get - they just care about getting the title (instance).

The scope of this feature is to implement what is needed to support title-level requesting.

Baseline requirements:
0) Title-level requests assume that all circulation logic (business logic) will reside within FOLIO and the discovery/presentation layer will only have the conditionalities to request and display the response from FOLIO's API's.
1) Title level requests focus on a single bibliographic/instance record (or equivalent, as CODEX and methods of title/instance/manifestation-level grouping may be built out in the future).
2) Title level requests focus on multiple copies of the same work, not separate volumes in a continuing work.
3) Title level requests assume the library user does not care which copy of the intellectual work (to use the FRBR vocabulary) or the instance (to use the FOLIO terminology) attached to a single or multiple holdings record. The library patron cares about obtaining a physical copy of the intellectual work.
4) For journal/serial records of a continuing work, item-specific requests can allow for specific volumes/years/parts to be requested.
4a) For journal/serial/continuing works with any/sizeable volume/years/parts with no individual item record or barcode), the Hold/Request form can compensate with a free text or NOTE field to allow the library user to specify which volume(s) is/are being requested.
4b) For journal/serial/continuing works with any/sizeable volume/years/parts with no individual item record or barcode) due to a Summary Holdings statement (or equivalent), the Hold/Request form can compensate with a free text or NOTE field to allow the library user to specify which volume is being requested.
5) Library can configure hold default at the tenant level. Some libraries will want an actual hold issued and other will choose to always issue a recall instead of an actual hold. In all cases below, when the discovery service issues a hold, this setting will determine of FOLIO actually issues a hold or a recall.
6) Follows all circulation policy as configured in circulation.

Discovery to FOLIO workflow:
I. The Discovery user is able to login to the campus SSO authentication system to personalize, as in the Identity provider returns a Y/N authentication flag, PLUS the FOLIO user's ID number (as in, a potentially anonymous, non-PII identifier that correlates the institutional user with their record in FOLIO)
II. The successful authentication allows the Discovery user to select/submit a hold/request button/operator on a physical item record.
III. THE Discovery RTAC+ API's send the authentication session cookie to FOLIO and uses the FOLIO user ID to request patron if patron has the rights to issue a request.
IV. If the user has the rights to issue a request, the discovery RTAC+ API's send the create hold/request action to FOLIO
V. FOLIO checks if any copies exist where loanable is true and if requests can be placed (do they have circ rights, or only reference copies or no copies). If no copies exist return reason why via API to Discovery service.
VI. If a copy is found that can circulate and it's not checked out, a page is issued on behalf of the patron on the 1st available copy.
VI. If all copies are out on loan, a hold/recall will be placed on the item with the fewest existing holds/recalls and the available date closest to today
VII. FOLIO returns status via API to Discovery service about success or failure of the request.

Acceptance criteria:
1. EDS or any other discovery service can issue holds successfully by patron while not adding functionality to issue pages or holds by item
2. EDS or any other discovery service can request and display holds (that represent FOLIO holds and/pages by item) successfully by patron while not adding functionality to issue pages or holds by item
3. EDS or any other discovery service can cancel/delete holds (that represent FOLIO holds and/pages by item) successfully by patron while not adding functionality to issue pages or holds by item
4. Get, Post & Delete in mod-circulation will modified with a new request type that operates on a title basis but internally to FOLIO as by item basis.
5. Greater than 80% test coverage
6. Deployed and merged into GIT with the FOLIO quarterly release.
7. For testing to be complete, and external discovery service will need to be configured. May require core platform team tasks.

Next Steps:
1. Further define/refine stories for breakdown
2. Define dependencies on core platform team
3. Make sure existing pattern set by renewals can accommodate this feature.