Bug 39187

Summary: Hold expiration date should not be extended if set by staff before hold is filled
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: Hold requestsAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: blawlor, gmcharlt, hannu.jokiranta, rcoert, tomascohen
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Nick Clemens (kidclamp) 2025-02-21 22:46:12 UTC
Koha respects a patron's set expiration for a hold when filling, and does not extend past the original date.

When a staff member places a hold for a patron the patron_expiration_date field is set.

If a staff member places a hold with no expiration, then sets the expiration before the hold has been filled, the expiration date will always be replaced by the default date from ReservesMaxPickupDelay

We should only replace the date if the new one is sooner.

To recreate:
1 - Place a hold in staff interface with no expiration date
2 - Edit the hold expiration date to be tomorrow
3 - Set ReservesMaxPickupDelay to 7
4 - Check in the item and confirm hold
5 - Expiration date is now 7 days away
Comment 1 Hannu Jokiranta 2025-03-27 09:06:42 UTC
I think the behaviour of patron_expiration_date should be set optional for libraries. There surely are different views on how this should work. We'd like it behave so that patron_expiration_date would only affect on how long the reservation is active. It should not affect the number of days a patron has for picking up the hold.

We've had several cases where the patron has had only 0-2 days to pick up the hold due the expiration date set by himself. Normally we give 7 days for picking up the holds. As we charge for expiring holds, extremely short times for picking up the holds are just not fair.