Requests (UXPROD-790)

[UXPROD-272] Requests: Paging requests (Basic) Created: 27/Feb/18  Updated: 16/Sep/20  Resolved: 10/Mar/19

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

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

Issue links:
Defines
is defined by CIRC-189 Backend Work for UIREQ-157: Support p... Closed
is defined by CIRC-207 Modify Allowed Recall to Item Status ... Closed
is defined by CIRC-208 Modify Allowed Hold to Item Status Co... Closed
is defined by UIREQ-157 Paging Request Creation and Handling Closed
is defined by UIREQ-208 Reorganize Fields on Request Record t... Closed
is defined by UIREQ-209 Pre-Filter Request Types Based on Whi... Closed
is defined by UIREQ-218 Display Popup When Request Prevented ... Closed
Relates
relates to UXPROD-1280 Paging Requests Individual Staff Slip Closed
relates to UXPROD-118 Fulfill pickup requests Closed
relates to UXPROD-1320 Customize built-in item statuses: con... Closed
Epic Link: Requests
Analysis Estimate: Small < 3 days
Analysis Estimator: Tania Fersenheim
Front End Estimate: Medium < 5 days
Front End Estimator: Matt Connolly
Front-End Confidence factor: Low
Back End Estimate: Large < 10 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: Includes the need to handle the impact of a request queue on item status when there isn't a loan
This means that the transitions for a request can happen at any point for an item
Assumes no changes to fulfilment of requests after creation
Assumes states where creation are allowed are hard-coded for the scope of this feature
Development Team: Prokopovych
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

Purpose: Implement paging requests (requests for not-checked-out items to be retrieved from stacks by staff and either placed on pickup shelf or delivered), including:

  • Staff slips (covered in UXPROD-1280 Closed ) and notices to the patron (covered in UXPROD-18 In Progress )
  • Service points that will be responsible for retrieving items
  • In app reports/list exports Covered in UXPROD-1138 Closed , UXPROD-923 Draft and UXPROD-1280 Closed
  • Closing of the request
  • Alerts at checkin, checkout and renewal that an item is wanted for a Paging request


 Comments   
Comment by Cate Boerema (Inactive) [ 09/Nov/18 ]

There are some questions we still need to answer (with SIG) about this feature:

  1. Are paging requests really needed if FOLIO supports the ability to configure which item states holds can be put on? This configurability is something we have been told we must absolutely have. If the only difference between a hold and a page is the item states on which they are allowed, I am not sure both are necessary
  2. Also, it seems that paging requests are not really any different from recalls and holds vis-a-vis how fulfillment is handled. Therefore, if we do go ahead with this feature, much of what is needed will already have been covered by UXPROD-118 Closed .

Given the remaining uncertainty and the fact that the development scope on this is smaller than originally thought, I think it makes sense to move this out of Q4 and into Q1 2019.

Comment by Marc Johnson [ 09/Nov/18 ]

Cate Boerema Tania Fersenheim at the moment, I believe it is only possible to create hold requests when an item is Checked out. (Changing this may impact the scenarios for check in and check out of items when looking at the request queue)

Which issues cover the configurable restriction on item status of hold requests?

Comment by Cate Boerema (Inactive) [ 09/Nov/18 ]

Which issues cover the configurable restriction on item status of hold requests?

Hi Marc Johnson. There isn't a feature for that yet (just learned of it recently). I can put something in the backlog: UXPROD-1320 Closed

Comment by Marc Johnson [ 09/Nov/18 ]

Cate Boerema That's all good, I just wondered if I missed something. Please, don't raise anything prematurely on my behalf. I'm just curious (and now I know I can defer thinking about it). Thank you.

Comment by Hkaplanian [ 13/Nov/18 ]

Does this imply that a person that wants to place a hold must determine if the title is available 1st and then make a decision about placing a hold vs request?

Comment by Uschi Klute [ 14/Nov/18 ]

Hkaplanian not the patron, but FOLIO
FOLIO should self-detect whether the item is

  • either on loan --> create hold request (perhaps incl. return request if desired by the library)
  • or available --> create paging request (incl. an automatically printed request slip)

Usually these are functions from the discovery system. In our experience requests are only carried out by staff in exceptional cases.

Indeed, I suppose that the staff user must distinguish between the two manifestations of an item (on loan/not on loan) and do the appropriate action.

Comment by Cate Boerema (Inactive) [ 15/Nov/18 ]

Does this imply that a person that wants to place a hold must determine if the title is available 1st and then make a decision about placing a hold vs request?

Hkaplanian, it depends. If there is only one type of request allowed per status, the system could make the determination, as Uschi Klute suggested. But many institutions allow more than one type of request for, say, checked out items (i.e. recall, hold). In this case, the requester does need to specify the type of request they are making. This is not a big deal when you are talking about recalls vs holds because there are clear implications (do you need it right away or can you wait for it to be checked back in at the normal due date). With holds and pages it is really not clear why you would choose one over the other. Hence my first comment here - I need to revisit this topic with the SIG to determine if we really need paging requests if we make the allowed item states configurable.

Comment by Cate Boerema (Inactive) [ 20/Nov/18 ]

Okay, the SIG confirmed that paging requests are needed. Highlights from our discussion:

  • While request to status mapping must be configurable, most institutions won't allow hold requests on available items ( UXPROD-1320 Closed )
  • For available items, they want to have a separate request type (paging request) so paging requests can have:
    • Different request policy rules
    • Different patron notices
    • Different system behavior, for example, related to impact of cancelling requests or automatic conversion of paging requests to ILL
Generated at Fri Feb 09 00:06:58 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.