Bug 14937 - Expiration date for holds based onReservesMaxPickUpDelay should not require ExpireReservesMaxPickUpDelay
Summary: Expiration date for holds based onReservesMaxPickUpDelay should not require E...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-01 16:58 UTC by Kyle M Hall
Modified: 2016-06-21 21:38 UTC (History)
4 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Trivial patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 14937 - Expiration date for holds based onReservesMaxPickUpDelay should not require ExpireReservesMaxPickUpDelay (2.03 KB, patch)
2015-10-01 17:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 14937 - Expiration date for holds based onReservesMaxPickUpDelay should not require ExpireReservesMaxPickUpDelay (2.09 KB, patch)
2015-10-13 19:54 UTC, Nicole C. Engard
Details | Diff | Splinter Review
Bug 14937 - Expiration date for holds based onReservesMaxPickUpDelay should not require ExpireReservesMaxPickUpDelay (2.15 KB, patch)
2015-10-15 09:04 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2015-10-01 16:58:43 UTC
C4::Letters::_parseletter will replace reserves.expirationdate with the date a hold will be marked as problematic ( holds over ) if both ReservesMaxPickUpDelay and ExpireReservesMaxPickUpDelay are enabled. There is no reason this feature needs to rely on ExpireReservesMaxPickUpDelay as there are many libraries that would like to send the last day to pick up a hold in notices, but would rather deal with the expired waiting holds manually rather than have Koha cancel them automatically.
Comment 1 Kyle M Hall 2015-10-01 17:01:40 UTC Comment hidden (obsolete)
Comment 2 Nicole C. Engard 2015-10-13 19:54:17 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2015-10-15 09:04:48 UTC
Created attachment 43417 [details] [review]
Bug 14937 - Expiration date for holds based onReservesMaxPickUpDelay should not require ExpireReservesMaxPickUpDelay

C4::Letters::_parseletter will replace reserves.expirationdate with the
date a hold will be marked as problematic ( holds over ) if both
ReservesMaxPickUpDelay and ExpireReservesMaxPickUpDelay are enabled.
There is no reason this feature needs to rely on
ExpireReservesMaxPickUpDelay as there are many libraries that would like
to send the last day to pick up a hold in notices, but would rather deal
with the expired waiting holds manually rather than have Koha cancel
them automatically.

Test Plan:
1) Apply this patch
2) Set ReservesMaxPickUpDelay to 7
3) Disable ExpireReservesMaxPickUpDelay
4) Add reserves.expirationdate to your HOLD notice
5) Fill a hold for a patron
6) View the message, not that reserves.expirationdate is replaced
   with the date the hold will be marked as problematic

Signed-off-by: Karl Holton <kholten@switchinc.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 4 Tomás Cohen Arazi 2015-10-19 15:54:53 UTC
Patch pushed to master.

Thanks Kyle!
Comment 5 Chris Cormack 2015-10-24 08:17:52 UTC
Pushed to 3.20.x will be in 3.20.5
Comment 6 Liz Rea 2015-11-02 21:13:55 UTC
Pushed to 3.18.x, is in 3.18.12.