Requests (UXPROD-790)

[UXPROD-3539] Default Setting for Request Expiration Period: Full Created: 02/Feb/22  Updated: 25/Sep/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P3
Reporter: Brooks Travis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: round_iv, v+v_candidate, volaris-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-1628 Default Setting for Request Expiratio... Analysis Complete
Defines
is defined by CIRC-1439 Apply default request expiration peri... Draft
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: covers ui-only implementation for staff interface to populate the expiration date field by default for staff-created requests
  • UXPROD-3539 (this feature): 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 defaut 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


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