Requests
(UXPROD-790)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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). Discovery to FOLIO workflow: Acceptance criteria: Next Steps: |
| 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. |
| 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, 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: Continuing work with much of the scenario adds a bit of complexity: 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 Holdings Record 1: Main Library, Copy 1, No Item Records 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. |
| 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? |