[Koha-bugs] [Bug 8367] How long is a hold waiting for pickup at a more granular level

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367

Olli-Antti Kivilahti <olli-antti.kivilahti at jns.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32786|0                           |1
        is obsolete|                            |

--- Comment #82 from Olli-Antti Kivilahti <olli-antti.kivilahti at jns.fi> ---
Created attachment 32826
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32826&action=edit
Bug 8367 - How long is a hold waiting for pickup at a more granular level

You can now specify a pickup delay for an hold function of a patron
category and/or a item type and/or a library.
The lastpickupdate-column is set based on the given instruction and lands only
on an
open library day.
Also cancel_expired_reserves.pl now cancels only on open library days after the
last pickup
date has expired.
And waitingreserves.pl respects the new DB column.

This patch adds:
- a new column in the issuing rules, including help topics.
- a new column reserves.lastpickupdate (+old_reserves)
  It contains the waitingdate + the corresponding "holds pickup wait".
  Each time the waitingdate is modified, this value will be modified too.
- a new field issuingrules.holdspickupwait
- a new function C4::Reserves::MoveWaitingdate() to help in testing this
feature.
- a new function C4::Reserves::GetLastPickupDate() to calculate the proper date
from Calendar.

This patch removes:
- the ReservesMaxPickUpDelay syspref.
- the ExpireReservesOnHolidays syspref, because it became obsolete due to the
changes in
  handling the last pickup date with Koha Calendar.
- Also removes a code section from C4::Letters::_parseLetter() which worked
blatantly
  disrespectfully towards Koha Calendar.
- TODO put the <<reserves.lastpickupdate>> as a placeholder in C4::Letters.
- TODO figure out how to rename existing letter placeholders <<expirationdate>>
with <<lastpickupdate>>

TODO Refactoring unit tests is in progress.

$$$$$$$$$$$$$
$ TEST PLAN $
$$$$$$$$$$$$$

          ****** ******
*** *** *** TEST: BASIC WORKFLOW *
          ****** ******
1. Check there is no regression with a normal reserve workflow.
2. Add one or more issuingrules.
3. Update the new column 'Holds pickup wait' in your issuing rules.
4. In 4 templates, you can see the 'Last pickup date' for an hold
   (circ/circulation.tt, circ/waitingreserves.tt, members/moremember.tt,
   opac-user.tt).
5. According to a library and an item type, the lastpickupdate value will be
   equal to the waiting date + the "holds pickup wait" defined.

          ** ** ** ** ** **
*** *** *** TEST: RESPECTING CALENDAR HOLIDAYS *
          ** ** ** ** ** **
1) Note your ReservesMaxPickUpDelay setting.
2) Create and trap a hold
3) View waitingreserves.pl, note the last pickup date, and the pickup
   location
4) Cancel this hold
5) Edit the calendar for the given location, and make the pickup date a
   single, unrepeated, holiday. Then make the next day a weekly repeating
holiday.
   Then make the next two days an annual holiday repeatable every year.
6) Repeat step 2
7) View waitingreserves.pl, the last pickup date for this new hold
   should now be increased by four days.

          ** ** ** ** ** **
*** *** *** TEST: LETTER lastpickupdate PLACEHOLDER AND REGRESSION *
          ** ** ** ** ** **
1. Modify the HOLD-letter, add <<reserves.lastpickupdate>> and
<<reserves.waitingdate>>
   somewhere.
2. Catch a hold for a borrower.
3. See the members/notices.pl for the message queued and verify that the
   lastpickupdate-placeholder is set in your desired datetime format and
   that it is not on a holiday. Verify that the waitingdate is today.

-- 
You are receiving this mail because:
You are watching all bug changes.