[Koha-bugs] [Bug 21932] New: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables)
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Sat Dec 1 21:02:52 CET 2018
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21932
Bug ID: 21932
Summary: reservetype and reserveexpiration needed for holds
(reserves and old_reserves tables)
Change sponsored?: ---
Product: Koha
Version: 17.05
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5 - low
Component: Hold requests
Assignee: koha-bugs at lists.koha-community.org
Reporter: cbrannon at cdalibrary.org
QA Contact: testopia at bugs.koha-community.org
CC: gmcharlt at gmail.com
I see an inherent flaw in the reserves table and process. If a hold is
waiting, and someone changes the status from waiting back to a priority level,
the waiting status is removed, but the expiration remains. Also, if the hold
was a first available hold, it is now changed to an item level hold for the
item it was on hold for.
I would suggest that a new field be created for the holds table, such as
reservetype, and is marked as 'ANY' or 'SPECIFIC'.
I would suggest that a new field be created for the reservation expiration
called reserveexpiration, separate from the waiting expiration, as to maintain
a reservation cutoff date if the status is changed back to a priority level.
This would make the expirationdate exclusive to waiting items.
I would suggest that when priority level is changed from waiting to a priority
level, the reservetype is checked, and if it is marked as ANY, the item number
be removed. If it is SPECIFIC, the item number is kept.
I would suggest that the expirationdate be cleared if changed from a waiting
status to a priority level.
I would suggest that all pages that show the "Expiration date" as the
reservationexpiration, if exists, or superseded by expirationdate, if exists.
No need to have a separate cell for both.
I would suggest that when a hold is triggered and marked as waiting, the
expiration date is calculated, or limited to the reservationexpiration,
whichever is shorter. No sense in holding it longer than the patron was
willing to wait for it.
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
More information about the Koha-bugs
mailing list