[Bug 43803] New: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Bug ID: 43803 Summary: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: arthur.suzuki@biblibre.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Target Milestone: --- Steps to reproduce: 1. Create an item-level hold on an item currently checked out to patron A (hold by patron B). 2. Workstation 1: check in the item. The "Hold found" modal appears with the "Confirm hold" button. Leave this modal open. 3. Workstation 2 (or another tab): check out the same item to patron C. The "This item is reserved" confirmation appears. Confirm the checkout without cancelling the hold (force checkout is allowed). 4. Back on workstation 1: click "Confirm hold" in the still-open modal. Expected result: The hold confirmation is refused (or the hold is left pending), because the item is now on loan. The hold should not be set to waiting while the item is checked out. Actual result: The hold is set to waiting (found = 'W') even though the item is on loan to patron C. The item ends up both on loan and on the hold shelf ("waiting for pickup"). No warning is shown to the librarian at step 4. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |arthur.suzuki@biblibre.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|--- |Sponsored Comma delimited| |BibLibre list of Sponsors| | Status|NEW |ASSIGNED Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 --- Comment #1 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 207937 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207937&action=edit Bug 43803: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 --- Comment #2 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 207938 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207938&action=edit Bug 43803: Do not set a hold waiting on an item checked out in the meantime When confirming a hold at checkin, the "Confirm hold" modal can stay open while the item is checked out again at another workstation (the checkout of a reserved item can be forced without cancelling the hold). Confirming the modal then called ModReserveAffect() unconditionally and set the hold to waiting even though the item was on loan, leaving the item both on loan and on the hold shelf. ModReserveAffect() now returns 0 and leaves the hold unchanged when the item is currently on loan and the hold is not already waiting. This protects all callers (returns.pl, circulation.pl, SIP checkin, hold autofill, branch transfers). circ/returns.pl displays a warning and skips the transfer creation in that case. Test plan: 1) Place an item-level hold on an item checked out to patron A (hold for patron B). 2) Check in the item: the "Hold found" modal appears. Leave it open. 3) From another tab or workstation, check out the item to patron C, confirming the checkout without cancelling the hold. 4) Back on the first tab, click "Confirm hold". => A warning is displayed ("The item has been checked out in the meantime: the hold has not been set aside and remains pending"), the hold is NOT set to waiting, and no transfer is created. 5) Check the item in again and confirm the hold normally. => The hold is set to waiting, the item appears on the hold shelf, and the transfer to the pickup library is created as usual. 6) Run: prove t/db_dependent/Circulation.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207937|0 |1 is obsolete| | Attachment #207938|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 --- Comment #3 from David Nind <david@davidnind.com> --- Created attachment 208001 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208001&action=edit Bug 43803: Unit tests Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 --- Comment #4 from David Nind <david@davidnind.com> --- Created attachment 208002 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208002&action=edit Bug 43803: Do not set a hold waiting on an item checked out in the meantime When confirming a hold at checkin, the "Confirm hold" modal can stay open while the item is checked out again at another workstation (the checkout of a reserved item can be forced without cancelling the hold). Confirming the modal then called ModReserveAffect() unconditionally and set the hold to waiting even though the item was on loan, leaving the item both on loan and on the hold shelf. ModReserveAffect() now returns 0 and leaves the hold unchanged when the item is currently on loan and the hold is not already waiting. This protects all callers (returns.pl, circulation.pl, SIP checkin, hold autofill, branch transfers). circ/returns.pl displays a warning and skips the transfer creation in that case. Test plan: 1) Place an item-level hold on an item checked out to patron A (hold for patron B). 2) Check in the item: the "Hold found" modal appears. Leave it open. 3) From another tab or workstation, check out the item to patron C, confirming the checkout without cancelling the hold. 4) Back on the first tab, click "Confirm hold". => A warning is displayed ("The item has been checked out in the meantime: the hold has not been set aside and remains pending"), the hold is NOT set to waiting, and no transfer is created. 5) Check the item in again and confirm the hold normally. => The hold is set to waiting, the item appears on the hold shelf, and the transfer to the pickup library is created as usual. 6) Run: prove t/db_dependent/Circulation.t Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org