Bug 11702 - Can't specify date for automatic resumption of suspended hold
Summary: Can't specify date for automatic resumption of suspended hold
Status: RESOLVED DUPLICATE of bug 11694
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Target Milestone: ---
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-06 17:08 UTC by Owen Leonard
Modified: 2014-02-27 14:19 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 11702 - Can't specify date for automatic resumption of suspended hold (2.15 KB, patch)
2014-02-06 17:30 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2014-02-06 17:08:50 UTC
If you suspend an individual hold in either the OPAC or staff client and specify a date for automatic resumption the date is not saved correctly.

To reproduce in the OPAC:

1. Turn on  RequestOnOpac, AutoResumeSuspendedHolds,
   and SuspendHoldsOpac 
2. Log in to the OPAC and place a hold
3. View the list of your existing holds (opac-user.pl)
4. Choose an individual hold to suspend, specify a suspend-until
   date, and submit
5. When the page reloads the hold will say "Suspended until 02/00/0"

To reproduce in the staff client:

1. Turn on AutoResumeSuspendedHolds and SuspendHoldsIntranet
2. Place a hold for a patron, or find an existing hold
3. View the hold details page for that hold
   (/cgi-bin/koha/reserve/request.pl?biblionumber=XX)
4. Specify a suspend-until date for the hold and submit
5. When the page reloads the hold will say "Unsuspend on"
   and show no date
Comment 1 Owen Leonard 2014-02-06 17:30:56 UTC
Created attachment 25103 [details] [review]
Bug 11702 - Can't specify date for automatic resumption of suspended hold

When suspending an individual hold in the OPAC or staff client the date
of resumption is saved as '000-00-00' no matter what dateformat setting
you use. This is not true of performing a suspend-all action.

This patch changes the date handling in C4::Reserves::ToggleSuspend to
match that in C4::Reserves::SuspendAll.

To test in the OPAC:

1. Turn on RequestOnOpac, AutoResumeSuspendedHolds, and
   SuspendHoldsOpac.
2. Log in to the OPAC and place a hold.
3. View the list of your existing holds (opac-user.pl).
4. Choose an individual hold to suspend, specify a suspend-until date,
   and submit.
5. When the page reloads the suspension should be saved with the correct
   resumption date.

Test using all dateformat system preference options. Also test
suspensions without resumption dates.

To test in the staff client:

1. Turn on AutoResumeSuspendedHolds and SuspendHoldsIntranet.
2. Place a hold for a patron, or find an existing hold.
3. View the hold details page for that hold
   (/cgi-bin/koha/reserve/request.pl?biblionumber=XX).
4. Specify a suspend-until date for the hold and submit.
5. When the page reloads the hold should say "Unsuspend on" and show the
   correct resumption date.

Test using all dateformat system preference options. Also test
suspensions without resumption dates.
Comment 2 Chris Cormack 2014-02-16 05:00:18 UTC
Owen, I think we are trying to move away from using C4::Dates ... is that correct Galen et al?
Comment 3 wajasu 2014-02-25 20:12:58 UTC
i tested without and with the patch(id=25103) and both worked as far as I could tell.  I just queried the reserves table with mysql and saw the same results.

But with Chris's comment #2, we should leave things be, until someone else can test to confirm my findings.
Comment 4 Kyle M Hall 2014-02-27 14:01:14 UTC
I believe the QA followup I posted for bug 11694 fixes this issue.
Comment 5 Owen Leonard 2014-02-27 14:19:20 UTC
(In reply to Kyle M Hall from comment #4)
> I believe the QA followup I posted for bug 11694 fixes this issue.

It does for me, so I'll close this as a duplicate.

*** This bug has been marked as a duplicate of bug 11694 ***