Requests (UXPROD-790)

[UXPROD-1630] Pre-Check Request Policy When Requests are Created and/or Moved Created: 26/Mar/19  Updated: 28/Sep/23  Resolved: 28/Sep/23

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

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: delegate_candidate, requests, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by CIRC-214 Provide an API for checking available... Closed
Duplicate
duplicates UXPROD-2689 Enable Request Policy to Determine Al... Closed
is duplicated by UIREQ-6 Immediate User Feedback if Request Pa... Closed
Relates
relates to UXPROD-2422 Discovery Integrations - Expose Circ... Open
relates to UXPROD-2758 Discovery Integrations - Expose Circu... Draft
Potential Workaround: Cate Boerema: Requests is functional as-is. This is a nice-to-have enhancement that would save a step.
Epic Link: Requests
Front-End Confidence factor: Medium
Back End Estimate: XL < 15 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: Assumes the introduction of a new API for providing which request types are allowed using the whitelist and the circulation rules / request policy, based upon the user and item.
Development Team: Vega
Kiwi Planning Points (DO NOT CHANGE): 1
PO Rank: 21
PO Ranking Note: 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R2
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R2
Rank: Lehigh (MVP Summer 2020): R2
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

When creating a request, FOLIO looks at the status of the item being requested and offers only the request types allowed per the whitelist. When the user clicks "create request", however, they may find that their request is still not allowed because of a request policy that has been applied. In this case, the user will see a popup letting them know that, for example, "A hold request is not allowed for this requester and item combination".

The purpose of this feature is to change the design so that the user doesn't need to click "New request" in order to find out that the request is not allowed. Instead, FOLIO will look at the selected item and requester, run them through the white list and the loan rules and then present only those request types that are allowed for that combination.

Per discussion with Marc Johnson, the same work needed to enable the above described functionality would also enable us to check the request policies and only show items to which a request can be moved in the move-request workflow (see UXPROD-1653 Closed ). Without this functionality, when moving a request, you will be presented with all other copies/items in the instance and you will only find the move is not allowed after you select one.

 

PO NOTE 2022-03-07: Could this be accomplished by calling the request policy circulation rules endpoint for the relevant items?



 Comments   
Comment by Anya [ 05/Apr/19 ]

FC : Would this apply to the API that would allow for Patron requests? Would the message display back to the patron? Or is this a Staff function only?

Comment by Cate Boerema (Inactive) [ 25/Apr/19 ]

FC : Would this apply to the API that would allow for Patron requests? Would the message display back to the patron? Or is this a Staff function only?

Maybe Marc Johnson can answer that question

Comment by Marc Johnson [ 25/Apr/19 ]

Anya Cate Boerema

Would this apply to the API that would allow for Patron requests?

What do you mean by the API for patron requests, are you referring to the API that is used by the regular FOLIO UI, or an API that could be used by an external discovery system (or similar) to allow a patron to make requests for themselves?

If it is the latter, as far as I am aware, that API does not yet exist.

When this is built, if it uses the internal API, then it would receive an error message when trying to create a request for a disallowed type.

If/when the API to provide a list of available request types is CIRC-214 Closed this could potentially be used by external systems to filter a list of request types.

There might need to be additional development to expose this via an edge module.

Comment by Anya [ 03/May/19 ]

FC - are do not have this currently, but this is the ideal workflow. And should include the edge API. It is nice for staff but has the most impact on patrons.

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

Marc Johnson could you please estimate this when you have a minute? Is it only backend or do we need a frontend estimate as well?

Comment by Cate Boerema (Inactive) [ 17/Jul/19 ]

Magda Zacharska what is the patron experience when they attempt to request an item that they are not allowed to request per request policy? I don't suppose there's any way for us to simply hide the request button/link when requests are prohibited by policy

Comment by Magda Zacharska [ 18/Jul/19 ]

Cate Boerema In EDS when the patron already placed the request for a given title, the "Place Hold" button is hidden. In all other scenarios a generic message "Sorry, this action is currently unavailable". Edge-patron log has more detailed error logged though.

Comment by Cate Boerema (Inactive) [ 18/Jul/19 ]

Thanks Magda Zacharska. Just want to make sure I understand. So let's say I'm an undergrad and I want to request a title which has two copies one which is a regular book and another that is a rare book. Request policy says I can request the item that is a regular book but I am not allowed to request the rare book copy. When I search up the book title in EDS and the copies/items are listed, does the Request button appear for both copies or just the one I am allowed to request?

Comment by Magda Zacharska [ 19/Jul/19 ]

Cate Boerema Since Item Level Request are not implemented in EDS yet, you see the Place Hold button on the title level. Both items are listed below the title but when a patron places a request, it is always created for the item that can be requested according to the request policy. So in your example, if both copies are available, the request is created for the copy you are allowed to request. If that that copy is checked out by someone else, and the copy you are not allowed to request is available, when you create a request, it will be added to the request queue for the copy you are entitled to request.

If a title has just one copy, and the copy cannot be requested by the patron according to the request policy, the Place Hold button is still visible but when the patron tries to place a request, the following message is displayed: "Sorry, this action is currently unavailable. Please try again or see your librarian for help."

Comment by Cate Boerema (Inactive) [ 30/Jul/19 ]

Thanks Magda Zacharska that's really useful information. We also discussed this in the RA SIG on July 18th and, while the notes don't make it explicit, I am pretty sure some SMEs (maybeDavid Bottorff and others?) indicated that they have implemented logic in discovery that displays/hides the request button per request policies. This logic, of course, needs to be kept in synch with the request policies in the ILS so it's not an ideal solution, but it is doable.

Comment by Holly Mistlebauer [ 07/Mar/22 ]

This feature is marked DRAFT until Brooks Travis has a chance to review it for validity.

Comment by Anne Ekblad [ 28/Sep/23 ]

Work described is in scope of UXPROD-2689 Closed (Enable Request Policy to Determine Allowed Pickup Service Points), which will be released in Poppy.

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