Requests (UXPROD-790)

[UXPROD-1320] Customize built-in item statuses: configure allowable request types per item status Created: 09/Nov/18  Updated: 24/Jan/24  Resolved: 15/Dec/22

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: Thomas Trutt
Resolution: Duplicate Votes: 0
Labels: requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Duplicate
duplicates UXPROD-3653 Item status: Requests - Customize ite... Draft
Relates
relates to UX-369 Mockup for CRU custom item statuses Open
relates to UXPROD-272 Requests: Paging requests (Basic) Closed
Potential Workaround: Cate Boerema: Rely on hard-coded mappings/whitelist currently in place. If an institution wants to further limit the kinds of requests a patron can make they can limit the options available through discovery (e.g. only allow discovery to initiate holds or recalls). Training can be used to limit the types of requests staff create. Finally, request policies will also limit the requests that can be made . In discussion with the RA SIG, this seemed like an approach many could live with until we had custom item states (see comments below).
Epic Link: Requests
Estimation Notes and Assumptions: This needs to be re-estimated once we have a better sense of the item status as reference values work (UXPROD-1927)
Development Team: Vega
PO Rank: 67
PO Ranking Note: 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Per SIG discussion, most could live without this until we had custom statuses. The go-live ranking don't seem to have been updated so I lowered using PO ranking
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R4
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

Some institutions allow holds on available items and other do not. Some allow holds on on order items while others don't. The purpose of this feature is to enable tenant level configuration of which requests types are allowed for which item statuses (availability). Per SIG, this feature becomes particularly important when we have implemented custom statuses. I have linked that feature up as related to this one ( UXPROD-1535 Draft )

Until this feature is implemented, the allowed item states for holds, recalls and page requests will be hard-coded as shown in the request whitelist document.

Notes added after estimates:

  1. When working out the design for this feature, we need to determine whether some institutions may want to have different request to item status configurations by location and how that would be handled.
  2. Also need to consider whether the other item states ("needed for" and "process") may need to factor into requestability

Initial wireframe: https://drive.google.com/file/d/1kBS0rJqqEVR1FB9nTT-YNbM5uDD0K-xE/view?usp=sharing



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

Marc Johnson, Michal Kuklis can you guys please estimate this when you have the chance? Let me know if you have questions. Thanks!

Comment by Marc Johnson [ 09/Nov/18 ]

Cate Boerema Jakub Skoczen I think this might need some thinking about the impact before I can sensibly estimate it.

I think we need to think about how this changes the flow of checking out an item and the upcoming transit checks for checking in an item. And, on the technical aspects, how we refer to item states and where this configuration is kept (and hence how mod-circulation gets it and the UI provides admin for it).

Do we need these estimates urgently?

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

Hi Marc Johnson, we do need some estimates so we can do the capacity planning for Q1 2019. Is it possible to add something rough (and conservative)? Can I help answer any of these questions?

Comment by Marc Johnson [ 12/Nov/18 ]

Cate Boerema Jakub Skoczen I've added a low backend confidence estimate with some assumptions (about the scope of the change, mostly from a technical perspective).

I haven't had chance to think through the processes that may be affected in detail. In general, I think this change means circulation has be prepared for a broader set of scenarios than before. And we need to consider this when each new status is introduced, to see if behaviour related to it could be impacted by this.

An example I thought of this morning was for requests for available items:
Given that one of the item states for creating requests is available
When an item is checked out
And there is an outstanding hold request
Then ...

Should it only allow check out to the requester (as is the current behaviour, based upon the request being awaiting pickup)? Which in effect would allow for pre-emptive holds e.g. a patron places a hold before heading to the library.

At the moment, the trigger for a staff member to place an item on the hold shelf (and the transition of the request to awaiting pickup status) is at check in (via the print slip dialog). As the item is not checked out, there is no need to check it in.

What could the trigger be for a staff member to action the hold request by fetching the item and placing it on the hold shelf (and hence awaiting pickup)? Or could we allow a request in any open state to be fulfilled by a check out?

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

Which in effect would allow for pre-emptive holds e.g. a patron places a hold before heading to the library.

A "pre-emptive hold" is pretty much exactly what a "Paging request" is (i.e. requests on items that are available). In fact, we are now asking ourselves if we even need paging requests if we can configure FOLIO to allow holds on available items (seems like it may be redundant - will discuss in SIG on Thursday).

What could the trigger be for a staff member to action the hold request by fetching the item and placing it on the hold shelf (and hence awaiting pickup)? Or could we allow a request in any open state to be fulfilled by a check out?

If I am understanding your question, the answer is that this is all done through check in. Let's say instead of paging requests, we just have hold requests allowed on available items. Here's how that would work:

  1. Hold request is created for an item that is available (someone calls the library and says "can you hold this for me - I'm coming in tomorrow)
  2. At some point in the day (often multiple times a day), someone at service point 1 generates a Requests csv export
  3. The export is filtered down to:
    • Type = Hold
    • Request status = Open - Not yet filled
    • Item status = Available (this filtering would need to be done in Excel, as we don't offer it in FOLIO yet)
    • Location = Shelving locations near service point 1 (would actually be ideal if the export included a column for the item's primary service point, but I don't think Tania included that in her list). This filtering would be done in excel or something since we don't yet support it in the UO
  4. They take this report to the shelves with a cart and pull the books
  5. They bring the books and scan them into Check In app
  6. The system will determine if they are Awaiting pickup or In transit according to the logic in UICHKIN-50 Closed and UICHKIN-49 Closed

BTW, the csv export is meant to be an interim step towards a more automated "pick list" report which would provide you with the list of items that need to be retrieved in a more automated way.

Comment by Charlotte Whitt [ 21/Nov/18 ]

The list of values we’d need to hard-code for Chalmers:

Item state Page Recall Inventory
Available Y N *
Awaiting pickup Y N
In transit Y N UICHKIN-17
Checked out N Y
Missing N N UIIN-252, accordion: Conditions
Recently returned Y N UICHKIN-39
On order Y N *

*) Meeting notes 11/21/2018 (Dennis Bridges, Craig McNally, Ann-Marie Breaux, Niels Erik Nielsen, Charlotte Whitt):
The Order app is in 'the bubble' and will probably not be ready for Q4 2018 to push Brief Order records (Instance associated with Holdings and Items) to Inventory. Craig and the FSE team will reach out to Niels Erik, when they are a little further, and Q1, 2019 is more likely the deadline.
Inventory can receive all the listed item state values, as hard coded values - wether they come from Order or Request app. Right now when an Item is created, the default value is set as Available. If Order is not providing the Item status 'On order' then this value must 'live' interim in another app - maybe Inventory?? And this interim solution to be deprecated ASAP when we can get the real Item state values from the Order app (On Order, Available and more).

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

Hi Charlotte Whitt. Some more info for your table above.

  • We do have the Awaiting pickup status already
  • In transit status is being created as part of UICHKIN-17 Closed
  • Recently returned status will be developed as part of UICHKIN-39 Closed

Thanks!

Comment by Charlotte Whitt [ 22/Nov/18 ]

Sounds great. I'll update the table above. Thanks! Cate Boerema

Comment by Marc Johnson [ 04/Dec/18 ]

Cate Boerema Is this to be a whitelist, where the states where request creation is allowed are defined, and all others are assumed to disallow?

Does this feature include the location specific variation of this?

Comment by Cate Boerema (Inactive) [ 04/Dec/18 ]

Is this to be a whitelist, where the states where request creation is allowed are defined, and all others are assumed to disallow?

I think that makes sense Marc Johnson

Does this feature include the location specific variation of this?

I think we can estimate assuming it doesn't for now. Looks like that's what you already did. Might make sense to just note that in the estimation assumptions, if so.

Thanks!

Comment by Anya [ 27/Jun/19 ]

FCs can live with a hard code for a while - but would like this soon.

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

Discussed in the RA SIG feature re-ranking. Discussion begins at 35:02 of this recording: https://drive.google.com/file/d/15RbACU90Ln4JAazWSz0iM4ZSYia6mIaK/view?usp=sharing

In general, the RA SIG felt this feature really didn't become important until we had custom statuses ( UXPROD-1535 Draft ) so I'm expecting ranks to be lowered (at the time of discussion, this was the top ranked Requests feature).

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

Updated Duke's ranking per Erin Nettifee's request. Duke comment is "needed once we have custom statuses"

Comment by David Bottorff [ 02/Jul/19 ]

Chicago will need this once we custom statuses as well, but can wait up to 1 year as long as the ASR statuses are coded at go-live.

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

Thanks for you comment David Bottorff. Did you want me to change the ranking on this for you? Chicago is still listed as go-live

Comment by David Bottorff [ 03/Jul/19 ]

Feel free to do so. I've sent the updates to Kristin Martin, who I assume has not had time to make the change yet.

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 Erin Nettifee [ 15/Dec/22 ]

Moving work over to UXPROD-3653 Draft .

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