Bug 8292 - clicking ignore on hold cancels transfer
Summary: clicking ignore on hold cancels transfer
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Target Milestone: ---
Assignee: Kyle M Hall
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 9322
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-22 13:33 UTC by Nicole C. Engard
Modified: 2016-08-18 23:23 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 8292 - clicking ignore on hold cancels transfer (6.75 KB, patch)
2012-10-10 14:27 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 8292 - clicking ignore on hold cancels transfer (6.78 KB, patch)
2013-01-02 01:44 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 8292 - Clicking ignore on hold cancels transfer (7.75 KB, patch)
2013-01-08 20:11 UTC, Owen Leonard
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 8292 - Clicking ignore on hold cancels transfer (8.26 KB, patch)
2013-01-24 22:04 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 8292 - Clicking ignore on hold cancels transfer (8.29 KB, patch)
2013-02-01 02:33 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-06-22 13:33:12 UTC
If a title has some holds on it and I check it in at the borrowing library, I got a message telling me about a hold.  I clicked "Ignore" on that message.  The barcode was not transferred back to the owning library at this point even though it should have been.  The barcode still shows as having a Current Location.

Notes from Ian on the code inspection:

The portion of code that triggers the automatic return home is not called if a hold is found; this makes sense in the case where you're filling the hold, since you'd be transferring to that library instead of the home library.

But when you 'ignore', nothing additional happens.  The ignore button just makes the confirmation box disappear; not further actions are taken.  So the code to do the transfer is never performed, and the item sits at the holdingbranch library.

Obviously this is not what people expect.  If you're ignoring the hold, you want the checkin to proceed as if the hold had never popped up in the first place, and that means doing a return home if appropriate.
Comment 1 Kyle M Hall 2012-10-10 14:27:50 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2012-10-16 13:35:31 UTC
CONFLICT (content): Merge conflict in C4/Circulation.pm
Comment 3 Chris Cormack 2013-01-02 01:44:07 UTC Comment hidden (obsolete)
Comment 4 Owen Leonard 2013-01-08 20:11:33 UTC Comment hidden (obsolete)
Comment 5 Katrin Fischer 2013-01-24 22:04:58 UTC Comment hidden (obsolete)
Comment 6 Jared Camins-Esakov 2013-01-31 20:29:12 UTC
I cannot get this problem to appear even without the patch. When I transfer the book from Library B, it gives me the option to ignore the hold. If I do that, nothing happens because the book is at library B. When the book arrives at library A, it does not give me the option of ignoring the hold because the book is already waiting. What am I missing here?
Comment 7 Liz Rea 2013-02-01 02:20:14 UTC
I sign off on this after thorough testing of this scenario:

Library A, B
Patrons 1a, 2b (letters denote which branch the patron is from)
Reserves 1, 2

Reserve 1 is placed for patron 2b
Reserve 2 is placed for patron 3c


Item is pulled from the shelf at library A (home library)
Checked in, for hold for patron 2b
Library clicks Confirm, sends item to B.
B checks in the item 
Clicks "Ignore"
Prompt says "Return to A" <- Good! Without the patch, this doesn't happen. 


However, and I think this is actually a different problem unrelated to this patch, but needs to be documented - 

Let's just say, that the staff member at B put it down on the desk (got interrupted) and another staff member picks up the book and checks it in again at library B.

This is what they will see:
http://i.imgur.com/AVGQTmK.png

and in the detail:
http://i.imgur.com/3z6K5iy.png

What should this new staff member do and what are those messages actually trying to say?

My point is, this patch greatly increases the likelihood of seeing dual prompts, and those prompts need to be made more understandable.
Comment 8 Liz Rea 2013-02-01 02:33:02 UTC
Created attachment 14990 [details] [review]
Bug 8292 - Clicking ignore on hold cancels transfer

Clicking 'ignore' in the hold confirmation box does nothing
but make the confirmation box disappear. No further actions are
taken. The code to do the transfer is never executed, and the item sits
at the holdingbranch library.

If you're ignoring the hold, you want the checkin to proceed as if the
hold had never popped up in the first place, and that means doing a
return home if appropriate.

To test, place a hold on an item for delivery to Library A. Check that
item in at Library B. Click "Ignore" in the hold confirmation message.
Before the patch, doing so would simply trigger JavaScript to hide the
dialog. After the patch the form will be sumitted and the item will be
transfered without fulfilling the hold.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Added description and test plan to the best of my understanding of what
this patch is trying to accomplish based on the bug report. The patch
works if I'm correct in my test plan.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.

Tests done:
1) Add an item hold on an item from library B for a patron from library A,
   pickup location is library A
2) Check in item at library A
3) Click 'ignore'
a) AutomaticItemReturn is ON = Koha provides a link to print the transfer
   slip.
b) AutomaticItemReturn is OFF = Koha provides 3 options: Confirm transfer
   and print slip, confirm transfer, don't confirm transfer.

Without the patch the item was returned, but the transfer wasn't triggered.

Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Comment 9 Liz Rea 2013-02-01 02:36:59 UTC
I want to also note, that if the item is checked in at library A, the next hold isn't triggered at check in. That behaviour probably has something to do with bug 9322, and I believe it's longstanding behaviour.
Comment 10 Jared Camins-Esakov 2013-02-02 08:07:45 UTC
I am not comfortable pushing this patch until the behavior the Liz describes in comment 9 is fixed (see also bug 9322, which Liz thinks may be the root cause of the unfillable holds issue). Right now, the behavior is annoying but predictable: click "Ignore," and the book isn't transferred. However, one can work around this by just sending the book where it belongs. With the patch, the book is transferred and -- so far as I can tell -- the next hold won't trigger at all, and I can't identify any workaround or think of a way to explain it to a librarian that will allow a multi-branch library to continue with business as usual.
Comment 11 Jared Camins-Esakov 2013-02-07 13:40:26 UTC
Changing to "In Discussion" until bug 9322 is sorted out.
Comment 12 Nicole C. Engard 2014-07-15 14:06:26 UTC
Just want to note that this happened again recently in Koha 3.14.  Are we really discussing? or has this report been left to die?
Comment 13 Owen Leonard 2014-07-15 14:18:11 UTC
(In reply to Nicole C. Engard from comment #12)
> or has this report been left to die?

I don't think that's a helpful thing to say.