Requests
(UXPROD-790)
|
|
| Status: | Analysis Complete |
| 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: | Unresolved | Votes: | 0 |
| Labels: | circ_po_small, delegate_candidate, round_iv, ui-only-candidate, v+v_candidate, volaris-candidate | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Requests | ||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | Medium < 5 days | ||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Michal Kuklis | ||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Matt Reno | ||||||||||||||||||||||||||||||||||||||||
| Development Team: | Vega | ||||||||||||||||||||||||||||||||||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 1 | ||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 47 | ||||||||||||||||||||||||||||||||||||||||
| 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): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
Split into two features:
FOLIO has both a "Request expiration date" and a "Hold shelf expiration date". The hold shelf expiration date is set when an item becomes "awaiting pickup" on the hold shelf based on a default expiry period set for the service point at which it's waiting. The request expiration date currently needs to be manually set, as there is no default. The purpose of this feature is to implement a default setting for request expiration period. Some members of the RA SIG felt that a tenant-level setting would suffice for this purpose while others thought it might be better to be able to set this default in the Request policy. More discussion is needed. Possible super thin thread: agreeing on a single default for everyone (6 months?) 2019-08-08 RA SIG Agreement: Thin thread of tenant-level setting is acceptable |
| Comments |
| Comment by Cate Boerema (Inactive) [ 15/May/19 ] |
|
Matt Reno and Matt Connolly could you please provide tshirt estimates for this feature? LMK if you have questions. |
| Comment by Matt Reno [ 16/May/19 ] |
|
Cate Boerema, I would think this is a M to L depending on where the setting is stored. If it is stored in something we already lookup when the request is created, then it will be simpler than having to add another API lookup to the request creation workflow. All in all, it sounds pretty straightforward. |
| Comment by Cate Boerema (Inactive) [ 20/May/19 ] |
|
Thanks Matt Reno! So, the level of effort would be lower if the setting was stored in the service point or the request policy but harder if it was stored as a tenant setting? Just want to make sure I understand as I think the SIG may be flexible on this. Also, could you please add your estimate to the Backend estimate field on this record and name yourself as the estimator? Matt Connolly, can you please do the frontend estimate? |
| Comment by Matt Reno [ 20/May/19 ] |
|
Cate Boerema Yes, that is what I was trying to convey. If this setting is part of something we already retrieve, the task is far simpler. If it is a new API, we may need to create new plumbing, hook it into the existing workflow, write tests, etc. I don't think it is any more difficult, it is just more work, if that makes sense. Note: I'll add the larger of the estimates until we have more clarity. |
| Comment by Cate Boerema (Inactive) [ 20/May/19 ] |
|
Michal Kuklis maybe you can do the frontend estimate for this since I am not hearing from Matt Connolly? |
| Comment by Matt Connolly [ 21/May/19 ] |
|
Sorry, Cate Boerema, I meant to do this on Friday before I left and have had spotty internet access since. Thanks for taking it, Michal Kuklis! |
| Comment by Brooks Travis [ 05/Feb/21 ] |
|
I know this doesn't solve the problem for staff-side requests, but could default request expiration be set by the discovery interface for patron-initiated requests? Just as a partial workaround. |
| Comment by Erin Nettifee [ 05/Apr/21 ] |
|
There's now code doing this in Users for patron groups - I wonder if that could be repurposed. |
| Comment by Khalilah Gambrell [ 12/Jan/22 ] |
|
Hey Brooks Travis, I assume this feature requires backend work? |
| Comment by Brooks Travis [ 12/Jan/22 ] |
|
I was thinking we would use mod-configuration to store the setting, which should mean it could be front-end only, no? |
| Comment by Brooks Travis [ 12/Jan/22 ] |
|
Sorry. Was thinking the thin-thread. I should have moved this to analysis complete. The full implementation would require back-end work, yes. |
| Comment by Brooks Travis [ 02/Feb/22 ] |
|
I've split this feature in two. One (this one) is UI-only and I'm going to move it into dev ready. The other (
|
| Comment by Brooks Travis [ 08/Feb/22 ] |
|
Stephanie Buck Let me know if you want me to present this feature to Vega at an upcoming refinement session. |
| 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 Stephanie Buck [ 05/Oct/22 ] |
|
Brooks Travis, can you confirm that the use case is the following: |
| Comment by Brooks Travis [ 08/Oct/22 ] |
|
Stephanie Buck that’s correct. It was split to allow one to be implemented as thin-thread UI-only, while still doing necessary work for the more involved back-end feature. |