Summary: | reservetype and reserveexpiration needed for holds (reserves and old_reserves tables) | ||
---|---|---|---|
Product: | Koha | Reporter: | Christopher Brannon <cbrannon> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | gmcharlt, lisettepalouse+koha |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: | Bug 21932: Fix REST API mapping |
Description
Christopher Brannon
2018-12-01 20:02:52 UTC
To test flaws: 1) Place a first available hold for the next available item, and set the hold expires date to a short time, like tomorrow. 2) Make sure your ReservesMaxPickUpDelay setting is set for longer that a day. Say 7 days, for example. 3) View the hold. Note the expiration date is set. 4) Check in the item and trigger the hold. See that the item is waiting. Note the expiration is set to the patron's preferred expiration date. 5) Set the priority back to 1, and update the hold. Note that the hold is now an item specific hold instead of a next available hold. 6) Note the expiration stayed. This is okay in this instance. 7) Cancel the hold and start over. 8) Place a first available hold for the next available item, but do not set the hold expires date. 9) View the hold. Note the expiration date is not set. 10) Check in the item and trigger the hold. See that the item is waiting. Not the expiration date is set. 11) Set the priority back to 1, and update the hold. Note that the hold is now an item specific hold instead of a next available hold. 12) Note the expiration stayed. This is not okay in this instance. The patron's hold will disappear after the date! It is noted that the waiting expiration date DOES adhere to the patron's suggested expiration, but I have spelled it out in my suggestions to maintain that behavior if the dates are recorded separately. Hi Christopher, partly good news here: The issue about reverting a hold to the right type (item-level, biblio-level) has been resolved: bug 9834 I'll mark this as duplicate of bug 21729, which discusses the remaining issue with the double-use of expirationdate. I agree with you that the right fix would be a separate database field in reserves and old_reserves. *** This bug has been marked as a duplicate of bug 21729 *** Created attachment 126163 [details] [review] Bug 21932: Fix REST API mapping It seems correct to not let third-party apps bypass the expiration date settings and so let them set patron_expiration_date but the calculated expirationdate. |