Requests (UXPROD-790)

[UXPROD-1061] Title-Level Requests (Basic) Created: 29/Aug/18  Updated: 03/Jan/24  Resolved: 26/Jun/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q2 2019
Parent: Requests

Type: New Feature Priority: P1
Reporter: Cate Boerema (Inactive) Assignee: Magda Zacharska
Resolution: Done Votes: 0
Labels: q1-2019-spillover, q2.2-2019, requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PDF File SimpleTLR.pdf     PNG File screenshot-1.png    
Issue links:
Defines
is defined by CIRC-271 Same Requester should not be allowed ... Closed
is defined by CIRC-245 Create and retrieve a Title Level Re... Closed
is defined by CIRC-264 Create and retrieve a Title Level Re... Closed
is defined by CIRC-265 Create and retrieve a Title Level Re... Closed
is defined by CIRC-267 Create endpoint for Title Level Requests Closed
is defined by MODPATRON-2 Title Level Requests: Add support for... Closed
is defined by MODPATRON-5 Title Level Requests: Set pickup loca... Closed
is defined by MODPATRON-8 Title Level Requests: Integrate with ... Closed
is defined by MODPATRON-12 Title Level Requests: Update the cir... Closed
Relates
relates to UXPROD-1217 Extending Loan Rules Editor to target... Closed
relates to UXPROD-1796 Title Level Requests Complete (part 1) Closed
relates to UXPROD-1982 Title Level Requests - Light - evalua... Closed
relates to CIRC-1164 Spike: Title Level Requests - analyze... Closed
relates to CIRC-1212 Spike: Title Level Requests - feature... Closed
relates to UXPROD-2198 Provide an instance level count of ex... Closed
relates to UXPROD-2311 Title Level Requests-Light - enable m... Closed
relates to UXPROD-1809 Title-Level Requests (Basic) - bug fi... Closed
relates to UXPROD-1810 Item-Level Requests - discovery servi... Closed
relates to UXPROD-351 Patron Portal Support (for Patron Fea... Closed
Epic Link: Requests
Back End Estimate: Large < 10 days
Estimation Notes and Assumptions: I am assuming a solution where the title (instance)-level request is immediately (at creation time) converted to a regular item-level request,
based on some simple logic, like take the first available item and if nothing is available the first one where the due date is soonest. This could be build as a new endpoint in mod-circulation or directly in mod-patron, if the usage is limited to discovery services.
Development Team: Prokopovych
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Lehigh (MVP Summer 2020): R5
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R1

 Description   

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.



 Comments   
Comment by Cate Boerema (Inactive) [ 29/Aug/18 ]

Hi Tania Fersenheim, has this come up in your discussions?

IIRC (and I did go digging around in old RA SIG notes), both item and title-level requesting were desired, but the thought was that, fundamentally, requests need to be associated with items for the proper functioning of the system. The notes from the discussion are pretty vague, but I seem to recall that title-level requests were thought of as kind of an extension of item-level requesting. That business logic (perhaps configurable) would need to be added to determine which item to put the request on when only title is specified by the requester. The determination would be made based on things like which item is due back soonest, which has the longest request queue etc. Does that sound right? Would you please raise this with the sub-group and update this feature with your learnings?

Comment by Hkaplanian [ 29/Aug/18 ]

If FOLIO moves forward with item level requests only, what happens when a student (through an OPAC or Discovery service) requests an item and that particular item or copy is currently on loan to a professor on campus? Who manages what happens?

Comment by Tania Fersenheim [ 29/Aug/18 ]

The decision to do item-level first predates my tenure on the RA SIG, but I do know that item-level requests are required for several critical functions, e.g. NCIP RequestItem which will be needed for integration with resource sharing systems such as Relais.

Comment by Tania Fersenheim [ 29/Aug/18 ]

Hkaplanian - If the item is on loan, and the patron has made a Recall request, the item will be recalled from the patron who has it on loan, according to the criteria that the institution sets up in FOLIO request policies.
If the item is on loan, and the patron has made a Hold request, when the item is eventually returned to the library it will be held for the patron who requested it.
FOLIO manages that behind the scenes. No staff intervention is needed, unless staff wish to manually alter the standard process for some reason.

Comment by Cate Boerema (Inactive) [ 28/Sep/18 ]

Marc Johnson and Matt Connolly, this new feature needs to be estimated. Tania Fersenheim will add more details but she thinks it probably warrants a meeting/discussion. Please reach out to her for more info.

Comment by Marc Keepper [ 05/Nov/18 ]

Marc Keepper adding detail to this Feature in order to add User Stories and build out the Title-Level Request development for FOLIO-EDS patron empowerment integration.

Comment by Hkaplanian [ 06/Nov/18 ]

Added some stories that I believe support RTAC functionality

Comment by Cate Boerema (Inactive) [ 15/Jan/19 ]

Due to reduced Core team capacity, this needs to be removed from Q1 2019 release.

Comment by Anya [ 29/Mar/19 ]

Comment from the March Meeting : NEEDED would love to test it soon

Comment by Lloyd Chittenden [ 21/Aug/19 ]

This is really not clear. Under baseline requirements part 2) says "Title level requests focus on multiple copies of the same work, not separate volumes in a continuing work." Then part 4) goes on to discuss continuing works. I don't know what this means.

Comment by Lloyd Chittenden [ 21/Aug/19 ]

The Estimation Notes and Assumptions says "I am assuming a solution where the title (instance)-level request is immediately (at creation time) converted to a regular item-level request,
based on some simple logic, like take the first available item and if nothing is available the first one where the due date is soonest."

This would not be good. We would want a hold queue that does not assign the request to an item until the item is actually available. The one due soonest my not be the one returned first. It may never come back at all. Then the request is stuck on a lost item that may not be fixed for a long time.

Comment by Marc Keepper [ 21/Aug/19 ]

Lloyd Chittendenl You wrote: This is really not clear. Under baseline requirements part 2) says "Title level requests focus on multiple copies of the same work, not separate volumes in a continuing work." Then part 4) goes on to discuss continuing works. I don't know what this means."

Let me add an example to see if it helps.

Title level requests focus on multiple copies of the same work, not separate volumes in a continuing work."

Easiest example:
Single instance record,
Single Holdings record with
3 Item Records attached/linked to the Single Holdings Record with copies 1, 2 & 3 of the same book.
3 different copies to 3 different Item Records: copy 1, copy 2, copy 3.
With this use case, the patron/user does not really care which of these 3 copies she receives in response to a request (or hold or page)

Continuing work with much of the scenario adds a bit of complexity:
Single instance record,
Single Holdings record with
3 Item Records attached/linked to the Single Holdings Record with volumes 1, 2 & 3 of the same multi-volume work
3 different volumes in 3 different Item Records: volume 1, volume 2, volume 3. (All copies are copy 1, but different volumes)
With this scenario, the patron/user intent is not yet clear.
User Intent Options:
Does the user want all 3 volumes of the work?
A single volume? If yes, which one?
Two volumes, but not all three? If yes, which yes & which no?

Request: Does that help at all?

If yes or not, please let me know either way. If yes, but more detail about continuing works, please let me know!

Comment by Lloyd Chittenden [ 21/Aug/19 ]

I am concerned about the scenario where there are multiple holdings records with multiple items attached and they are all checked out in a consortium. Such as a DVD of a TV series like Game of Thrones. Let's say the user wants season 6. A title level request is bad because they could get any season. An item level request is bad because we don't know which item will come back first, or at all. Then some other user could get the next available one even if they put in a later request, or this request could get stuck for a long time if it is not returned. I want to see a request queue at the holdings level that will give the first item attached to that holding anywhere in the consortium to the next person in the queue. This is a very common situation for a public library consortium.

Comment by Hkaplanian [ 22/Aug/19 ]

Lloyd Chittenden, Right now FOLIO lacks consortia functionality. Those features are currently being defined in the FOLIO Consortia SIG. This would be a great topic to bring up with that group. Also, this feature as defined is a bit of a stop gap measure until some other aspects of FOLIO are built. We do expect this functionality to change and greatly improve in later FOLIO releases.

Comment by Marc Keepper [ 22/Aug/19 ]

Lloyd, agreed this is very common. The scenario is also very true when academic libraries have backfile runs of continuing works like journals/serials.

The use case you provided is very common for public libraries, namely: "there are multiple holdings records with multiple items attached and they are all checked out in a consortium. Such as a DVD of a TV series like Game of Thrones. Let's say the user wants season 6. A title level request is bad because they could get any season. An item level request is bad because we don't know which item will come back first, or at all. Then some other user could get the next available one even if they put in a later request, or this request could get stuck for a long time if it is not returned. I want to see a request queue at the holdings level that will give the first item attached to that holding anywhere in the consortium to the next person in the queue. This is a very common situation for a public library consortium."

In response to this use case, I believe that the existing title level Holding/Request queue in EDS and participating library systems (like OCLC WMS, and FOLIO) has always allowed the first available copy to become available to the first/earliest patron in the Hold/Request queue. That works well without the extra layers of complexity of multiple holdings/items/copies corresponding to multiple libraries (members of a consortium) and each items record may not be a copy number but a specific volume, issue, part, season (or other content/organizational unit).

Question: Have you talked with Harry Kaplanian and/or Martin Tran about this scenario yet?

I would add the academic use case of a journal run volumes 1- volume 50. There might be 4 copies, 3 holdings, and only 50 item records.

Single Instance Record
3 Holdings Records
50 Item Records with this scenario.

Holdings Record 1: Main Library, Copy 1, No Item Records
Holdings Record 1: Main Library, Copy 2, No Item Records
Holdings Record 2: Law Library, Copy 1, No Item Records
Holdings Record 3: Remote Storage, Copy 1, Each of the 50 volumes has a single Item Record with Barcode

In this scenario, the user may not care which copy she receives in response to her request. hold or page. However, she will care about which specific volumes she receives.

In the existing/older RTAC+ functionality availability for patron empowerment, all of the requests/holds/pages were title level and there was a free text field added to the user display painted on the EDS screen. This free text field allowed the patron to request specific volume(s).

You may already know this, but just to confirm. The 2 holdings & 3 copies without any item records have a summary holding statement with MARC 21 data like this in the source record storage:

866 31$80$a1-86 (1941-1987)$xbound in 2 v. per year$zSome issues missing

[Added info worth confirming: The 866 field replaces both 863 fields. The library records actual detailed holdings in the 863 fields, but the display shows summary holdings with non-public and public notes.]

Again, I'd check in with Hkaplanian, Magda Zacharska and/or Martin Tran

Hope this is somewhat helpful.

Marc

Comment by Lloyd Chittenden [ 22/Aug/19 ]

Hkaplanian I started in the Consortia SIG. They suggested I look at this UXPROD to see if it was the solution to this issue. I have put this in as a user story over there. I'm clarifying that this does not fix the problem, so I can continue to press the issue in the Consortia SIG.

Comment by Hkaplanian [ 22/Aug/19 ]

Lloyd Chittenden - Got it. Make sense. Let me know if I can help.

Comment by Lloyd Chittenden [ 22/Aug/19 ]

Marc Keepper It sounds like you are talking about a multi-tenant consortium. This would indeed be very messy in that scenario, however our consortium is set up with a single server where everyone is sharing the same bib records. If we had holdings records we would share those as well, primarily because it would facilitate exactly this sort of resource sharing.

So we would be talking about a single MARC record for the TV series, with a single holdings record for each season. Then every library would have it's copies of each season attached to that single holdings record. Then it is not complicated. I'm suggesting that the requests should exist on the holdings record rather than the title level or the item level. If you had holdings level requests, then you would not need title level requests at all because if there is only one holdings record, then they are the same thing. And item level requests could be added, but it would be a lower priority because the need to request a particular copy of a volume is rare.

I will continue to pursue this in the Consortia SIG, but the people developing this function here should know that this is wanted. I don't know that it would be so much harder to start out with a system of requests at the holdings level rather than title level. If that's where we want to be in the end, it might be easier to set it up that way now rather than build title level requesting and have to add holdings level requesting later.

HkaplanianMagda ZacharskaMartin Tran

Comment by Magda Zacharska [ 23/Aug/19 ]

Lloyd Chittenden The functionality you are concerned about is outside the scope of this feature (basic title level request) but we have solution that could handle the situation that on one occasion a patron doesn't care which copy their will get (identical copies for the same bib rec) and on the other (like different seasons of the TV series). This is being handled by the discovery service that is integrated with FOLIO through edge modules. We have it working with EDS integration. Here is an example of the modal that is displayed to the patron when creating a request for multi-volume publication:

Comment by Lloyd Chittenden [ 23/Aug/19 ]

Magda ZacharskaThank you. That is very interesting. Where do I find that part of the project on Jira? I'm new to this and it is not so easy to navigate.

Comment by Magda Zacharska [ 24/Aug/19 ]

Lloyd Chittenden You might want to take a look at https://github.com/folio-org/edge-rtac, https://github.com/folio-org/edge-patron, https://github.com/folio-org/mod-patron and https://github.com/folio-org/mod-rtac. If you have technical questions Matt Reno or Martin Tran would be the best to contact. If you have questions regarding the functional side - please let me know.

Comment by Lloyd Chittenden [ 26/Aug/19 ]

Magda Zacharska Is there a sandbox version of this functionality that I could try out?

Generated at Fri Feb 09 00:12:38 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.