https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #100141|0 |1 is obsolete| | --- Comment #2 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 100155 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100155&action=edit Bug 24802: Updating holds can cause suspensions to apply to wrong hold On request.pl, the table of holds shows a suspend_until date picker for each hold, *unless* that hold is waiting or in transit. The script reserve/modrequest.pl assumes that there will be a suspend_until input for each hold, but that is incorrect. Assume there are 20 holds on a record, and 10 of them are waiting or in transit. If you were to then set the suspend until date on the 10 open holds, and use the "Update hold(s)" button, those 10 suspensions would apply to the 10 found holds and not the holds they should apply to! Test Plan: 1) Place two holds on a record 2) Check in an item and trap it for the first hold 3) Now that one hold is waiting and the other is not, attempt to set a suspension date using the "Update hold(s)" button 4) Note your hold does not get suspended! 5) Apply this patch 6) Restart all the things! 7) Repeat steps 1-3 8) Your hold should now be suspended! Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | Status|Signed Off |BLOCKED CC| |m.de.rooy@rijksmuseum.nl --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- QAing -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #100155|0 |1 is obsolete| | --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 100216 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100216&action=edit Bug 24802: Updating holds can cause suspensions to apply to wrong hold On request.pl, the table of holds shows a suspend_until date picker for each hold, *unless* that hold is waiting or in transit. The script reserve/modrequest.pl assumes that there will be a suspend_until input for each hold, but that is incorrect. Assume there are 20 holds on a record, and 10 of them are waiting or in transit. If you were to then set the suspend until date on the 10 open holds, and use the "Update hold(s)" button, those 10 suspensions would apply to the 10 found holds and not the holds they should apply to! Test Plan: 1) Place two holds on a record 2) Check in an item and trap it for the first hold 3) Now that one hold is waiting and the other is not, attempt to set a suspension date using the "Update hold(s)" button 4) Note your hold does not get suspended! 5) Apply this patch 6) Restart all the things! 7) Repeat steps 1-3 8) Your hold should now be suspended! Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Nice work everyone! Pushed to master for 20.05 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #7 from Lucas Gass <lucas@bywatersolutions.com> --- attempted to rebase and all seems good, test plan works but I fail the qa tool: FAIL reserve/modrequest.pl OK critic OK forbidden patterns OK git manipulation OK pod OK spelling FAIL valid Global symbol "@reservedates" requires explicit package name (did you forget to declare "my @reservedates"?) Global symbol "@reservedates" requires explicit package name (did you forget to declare "my @reservedates"?) reserve/modrequest.pl had compilation errors. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24802 --- Comment #9 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 102811 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=102811&action=edit Bug 24802 [19.05]: Updating holds can cause suspensions to apply to wrong hold On request.pl, the table of holds shows a suspend_until date picker for each hold, *unless* that hold is waiting or in transit. The script reserve/modrequest.pl assumes that there will be a suspend_until input for each hold, but that is incorrect. Assume there are 20 holds on a record, and 10 of them are waiting or in transit. If you were to then set the suspend until date on the 10 open holds, and use the "Update hold(s)" button, those 10 suspensions would apply to the 10 found holds and not the holds they should apply to! Test Plan: 1) Place two holds on a record 2) Check in an item and trap it for the first hold 3) Now that one hold is waiting and the other is not, attempt to set a suspension date using the "Update hold(s)" button 4) Note your hold does not get suspended! 5) Apply this patch 6) Restart all the things! 7) Repeat steps 1-3 8) Your hold should now be suspended! Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Joy Nelson <joy@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.