If an item that fills a hold request is checked in twice and the hold is confirmed each time, it is possible for multiple hold notifications to be sent to the patron even if the item was already marked as waiting on the hold shelf after the first checkin. This is because ModReserveAffect() includes a call to GetReserveInfo() that was never updated when the holds API was updated to use reserve_id. Consequently, ModReserveAffect fails to correctly determine if the item was already waiting.
Created attachment 23811 [details] [review] Bug 11445: regression test for duplicate hold notifications This patch implements a regression test for verifying that duplicate hold notifications aren't sent if ModReserveAffect() is called repeatedly (as might happen if a circ operator accidentally checks in an item and confirms its hold more than once). Note that the test depends on the fact that _koha_notify_reserve() defaults to sending a HOLD_PRINT letter if the borrower has not specified an email or SMS hold notification. To test: [1] Run prove -v t/db_dependent/Reserves.t [2] The 'patron not notified a second time (bug 11445)' test should fail. [3] Apply the main patch and run prove -v t/db_dependent/Reserves.t again. This time all tests should pass. Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Created attachment 23812 [details] [review] Bug 11445: avoid sending duplicate hold waiting notifications This patch fixes a problem where a patron could receive duplicate hold waiting notifications. For example, this could happen if a circ operator checked in an item more than once and confirmed the same hold each time. To test: [1] Set up a test patron that received hold waiting notifications. [2] Put an item on hold for the patron, then check the item in and confirm the hold. Verify that a hold notification is sent (or inspect the message_queue table). [3] Check the item in again and confirm the hold again. A duplicate hold notification will be generated. [4] Apply the patch. [5] Repeat steps 2 and 3. This time, only one notification should be generated. [6] Verify that prove -v t/db_dependent/Reserves.t passes. Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Created attachment 23842 [details] [review] Bug 11445: regression test for duplicate hold notifications This patch implements a regression test for verifying that duplicate hold notifications aren't sent if ModReserveAffect() is called repeatedly (as might happen if a circ operator accidentally checks in an item and confirms its hold more than once). Note that the test depends on the fact that _koha_notify_reserve() defaults to sending a HOLD_PRINT letter if the borrower has not specified an email or SMS hold notification. To test: [1] Run prove -v t/db_dependent/Reserves.t [2] The 'patron not notified a second time (bug 11445)' test should fail. [3] Apply the main patch and run prove -v t/db_dependent/Reserves.t again. This time all tests should pass. Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 23843 [details] [review] Bug 11445: avoid sending duplicate hold waiting notifications This patch fixes a problem where a patron could receive duplicate hold waiting notifications. For example, this could happen if a circ operator checked in an item more than once and confirmed the same hold each time. To test: [1] Set up a test patron that received hold waiting notifications. [2] Put an item on hold for the patron, then check the item in and confirm the hold. Verify that a hold notification is sent (or inspect the message_queue table). [3] Check the item in again and confirm the hold again. A duplicate hold notification will be generated. [4] Apply the patch. [5] Repeat steps 2 and 3. This time, only one notification should be generated. [6] Verify that prove -v t/db_dependent/Reserves.t passes. Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 23852 [details] [review] [PASSED QA] Bug 11445: regression test for duplicate hold notifications This patch implements a regression test for verifying that duplicate hold notifications aren't sent if ModReserveAffect() is called repeatedly (as might happen if a circ operator accidentally checks in an item and confirms its hold more than once). Note that the test depends on the fact that _koha_notify_reserve() defaults to sending a HOLD_PRINT letter if the borrower has not specified an email or SMS hold notification. To test: [1] Run prove -v t/db_dependent/Reserves.t [2] The 'patron not notified a second time (bug 11445)' test should fail. [3] Apply the main patch and run prove -v t/db_dependent/Reserves.t again. This time all tests should pass. Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Created attachment 23853 [details] [review] [PASSED QA] Bug 11445: avoid sending duplicate hold waiting notifications This patch fixes a problem where a patron could receive duplicate hold waiting notifications. For example, this could happen if a circ operator checked in an item more than once and confirmed the same hold each time. To test: [1] Set up a test patron that received hold waiting notifications. [2] Put an item on hold for the patron, then check the item in and confirm the hold. Verify that a hold notification is sent (or inspect the message_queue table). [3] Check the item in again and confirm the hold again. A duplicate hold notification will be generated. [4] Apply the patch. [5] Repeat steps 2 and 3. This time, only one notification should be generated. [6] Verify that prove -v t/db_dependent/Reserves.t passes. Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Passes all tests and QA script. Works as described.
Pushed to master.
Patches pushed to 3.14.x, will be in 3.14.3.