[Koha-bugs] [Bug 8367] How long is a hold waiting for pickup at a more granular level
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Tue Aug 13 15:10:14 CEST 2013
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367
Jonathan Druart <jonathan.druart at biblibre.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #19180|0 |1
is obsolete| |
Attachment #19182|0 |1
is obsolete| |
Attachment #19360|0 |1
is obsolete| |
Attachment #19362|0 |1
is obsolete| |
--- Comment #69 from Jonathan Druart <jonathan.druart at biblibre.com> ---
Created attachment 20300
-->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20300&action=edit
Bug 8367: Add more granular level for ReservesMaxPickUpDelay
This patch adds:
- a new column in the issuing rules
- a new column reserves.maxpickupdate (+old_reserves)
It contains the waitingdate + the corresponding max pickup delay.
Each time the waitingdate is modified, this value will be modified too.
- a new field issuingrules.holdspickupdelay
This patch removes the ReservesMaxPickUpDelay syspref.
The update database script will update the issuingrules table with the
correct value before removing it.
You can now specify a pickup delay for an hold function of a patron
category and/or a item type and/or a library.
To test:
Check there is no regression with a normal reserve workflow.
Add one or more issuingrules.
Update the new column 'Holds pickup delay' in your issuing rules.
In 4 templates, you can see the max pickup delay for an hold
(circ/circulation.tt, circ/waitingreserves.tt, members/moremember.tt,
opac-user.tt).
According to a library and an item type, the maxpickupdate value will be
equal to the waiting date + the pickup delay defined.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
--
You are receiving this mail because:
You are watching all bug changes.
More information about the Koha-bugs
mailing list