Bug 10949: restore ability to successfully print hold slips
authorGalen Charlton <gmc@esilibrary.com>
Wed, 25 Sep 2013 16:15:07 +0000 (16:15 +0000)
committerGalen Charlton <gmc@esilibrary.com>
Wed, 2 Oct 2013 14:38:30 +0000 (14:38 +0000)
commit11606693ef6026093d55ea652db083e90ccc6ffe
tree6cca8338b80268035e6c240f58a300c72596116b
parent090ba4902cbd04634caa5fd507a2672b0987d795
Bug 10949: restore ability to successfully print hold slips

This fixes a regression introduced by the patch for bug
9394 -- when printing a hold slip using the 'print and confirm'
button, the slip would contain only the text 'reserve not found',
not a full hold slip.

This patch also adds a regression test.

To test:

[1] Check in an item that would fill a hold.  Use the 'print
    and confirm button' to confirm the hold.
[2] The printout will only contain text to the effect of
    'reserve not found'.
[3] Apply the patch.
[4] Repeat step 1.  This time, a full hold slip should be printed.
[5] Verify that prove -v t/db_dependent/Reserves.t passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Pass all tests, new and old, and QA script.
Verified wrong and corrected behaviour.

Note: Sometimes there will not be the message 'reserve not found'
showing up, but hold information for a different record. This happens
when there exists a reserve_id with the borrowernumber of the patron
in question in your database.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
C4/Reserves.pm
t/db_dependent/Reserves.t