Requests (UXPROD-790)

[UXPROD-1628] Default Setting for Request Expiration Period: Staff UI-only Created: 26/Mar/19  Updated: 09/Oct/23

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:
Blocks
blocks CIRC-1439 Apply default request expiration peri... Draft
Cloners
is cloned by UXPROD-1629 Filter Requests by Pickup Service Point Closed
is cloned by UXPROD-3539 Default Setting for Request Expiratio... Draft
Defines
is defined by UICIRC-728 Create a Setting in Settings > Circul... Open
is defined by UIREQ-676 Use Default Request Expiration Date S... Open
Relates
relates to UX-476 Mock up UI example for Tenant-level D... In Progress
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:

  • UXPROD-1628 Analysis Complete (this feature): covers ui-only implementation for staff interface to populate the expiration date field by default for staff-created requests
  • UXPROD-3539: covers back-end implementation and related patron-facing stories (eg. mod-patron/mod-edge-patron)

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 ( UXPROD-3539 Draft ) will represent the work to support enforcing the default on the back-end and exposing it to patron-facing interfaces (if necessary).

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: 
Staff needs a request expiration date to be set automatically (rather than manually) when a request is placed so that unfulfilled request don't linger. 
Question two - what was the reason for splitting this into two features?

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.

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