Requests
(UXPROD-790)
|
|
| 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: |
|
||||||||||||||||||||
| 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 (
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:
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: 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 ] | ||||||||||||||||||||||||||||||||
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).
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:
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:
*) Meeting notes 11/21/2018 (Dennis Bridges, Craig McNally, Ann-Marie Breaux, Niels Erik Nielsen, Charlotte Whitt): | ||||||||||||||||||||||||||||||||
| Comment by Cate Boerema (Inactive) [ 22/Nov/18 ] | ||||||||||||||||||||||||||||||||
|
Hi Charlotte Whitt. Some more info for your table above.
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 ] | ||||||||||||||||||||||||||||||||
I think that makes sense Marc Johnson
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 (
| ||||||||||||||||||||||||||||||||
| 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
|