Bug 4040 - Placing a hold on an item while it is in transit results in duplicate dialogs upon check-in
Summary: Placing a hold on an item while it is in transit results in duplicate dialogs...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-12 05:07 UTC by Owen Leonard
Modified: 2023-12-28 20:42 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot (13.50 KB, image/png)
2010-01-12 17:07 UTC, Chris Cormack
Details
Proposed patch (1.09 KB, application/octet-stream)
2011-03-30 17:03 UTC, Liz Rea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:22:26 UTC


---- Reported by oleonard@myacpl.org 2010-01-12 17:07:58 ----

Created an attachment
Screenshot

To reproduce:

- Item is on hold for a patron at Branch A.
- Item is checked in at Branch B, transfer is confirmed.
- Item is checked in again at Branch B, duplicate dialogs are displayed.

The first dialog says "Please return [title] : to [branch] Hold for..." and displays the patron's information. No indication that the item should be transfered.

The second dialog says "Hold Found: [title] : Hold for..." and displays the patron's information. Below that is the standard "Transfer to [branch]" and the "Confirm hold and transfer" button.

See attached image.



---- Additional Comments From oleonard@myacpl.org 2010-01-12 21:00:38 ----

Further investigation shows that two conditions are being met simultaneously:

- "WrongTransfer," set at line 283 of returns.pl
- "reserved," set at line 327 of returns.pl




---- Additional Comments From oleonard@myacpl.org 2010-02-18 19:20:57 ----

This will also happen if under these circumstances:

1. Item is in-transit between Branch A and Branch B.
2. Item is placed on hold.
3. Item is checked in at Branch C.

It makes sense, then, that "WrongTransfer" and "reserved" are both being triggered: Koha expects the item to be heading for a different branch, so it's warning you ("WrongTransfer") that the book should go elsewhere. But it's also noticing the hold, so it's giving you that message too ("reserved").

The "reserved" message is all that is needed because it is a higher priority message.



---- Additional Comments From oleonard@myacpl.org 2010-02-18 19:31:53 ----

A more specific version of that example:

1. Item is in-transit between Branch A and Branch B.
2. Item is placed on hold for patron at Branch C.
3. Item is checked in at Branch C.

At step 1, Koha expects the item to be transferred to Branch B.
At step 3, Koha expects the item to be sent to be held at Branch C (to fulfill the hold) AND transferred to Branch B (to complete the transfer).



---- Additional Comments From oleonard@myacpl.org 2010-02-18 19:49:50 ----

Even more data:

1. Item from Branch A is checked in at Branch B, automatically transferred to Branch B:

+------------+------------+--------------+----------+----------+
| itemnumber | frombranch | datearrived  | tobranch | comments |
+------------+------------+--------------+----------+----------+
|       1432 | A          | NULL         | B        |NULL      | 
+------------+------------+--------------+----------+----------+

2. A hold is placed on the item by a patron at Branch C.

3. Item is checked in at Branch D, hold is confirmed.

+------------+------------+--------------+----------+----------+
| itemnumber | frombranch | datearrived  | tobranch | comments |
+------------+------------+--------------+----------+----------+
|       1432 | A          | NULL         | B        | NULL     | 
|       1432 | D          | NULL         | C        | NULL     | 
+------------+------------+--------------+----------+----------+

The item is now simultaneously in-transit to two different branches.

Looks like we need automatically cancel any open transfers for an itemnumber if that itemnumber is being transferred for a hold.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:22 UTC  ---

This bug was previously known as _bug_ 4040 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4040
Imported an attachment (id=1798)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
The original submitter of attachment 1798 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 D Ruth Holloway 2011-03-30 13:37:22 UTC
The fix for Bug 6004 seems to fix all but the last of these circumstances at current HEAD.
Comment 2 Liz Rea 2011-03-30 17:02:29 UTC
Fix by D Ruth Bavousett fixes this.
Comment 3 Liz Rea 2011-03-30 17:03:50 UTC
Created attachment 3539 [details]
Proposed patch
Comment 4 Chris Cormack 2011-03-31 07:43:08 UTC
Did the signed off patch get sent? I cant find it
Comment 5 Jared Camins-Esakov 2011-03-31 12:50:50 UTC
It was sent as the patch for bug 4040, and pushed last night.
Comment 6 Owen Leonard 2011-03-31 13:00:54 UTC
> It was sent as the patch for bug 4040

Bug 6004.
Comment 7 Jared Camins-Esakov 2011-03-31 13:02:47 UTC
Right. No coffee this morning. ;)
Comment 8 Owen Leonard 2011-03-31 13:21:27 UTC
The first example (2010-01-12 17:07:58) has been fixed with the patch for Bug 6004. The second (2010-02-18 19:20:57) and third (2010-02-18 19:31:53) have not.
Comment 9 Katrin Fischer 2013-03-24 18:19:21 UTC
Owen, can you take another look at this maybe? Is it still a problem?
Comment 10 Marc Véron 2016-08-19 09:11:13 UTC
Still valid?
Comment 11 Katrin Fischer 2019-05-04 13:54:16 UTC
Requires re-testing.
Comment 12 Katrin Fischer 2023-01-07 22:22:07 UTC
I tried testing this (hopefully correctly).

There is only one dialog now consistently that asks for "confirm hold and transfer".

I believe the current behaviour is correct, please reopen if I missed something!