Bug 2838 - Checking in an in-transit item to its originating branch causes improper error message(s)
Summary: Checking in an in-transit item to its originating branch causes improper erro...
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: PC All
: P3 normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-02 11:37 UTC by Chris Cormack
Modified: 2023-06-08 22:26 UTC (History)
5 users (show)

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


Attachments
transit error wrong (14.13 KB, image/png)
2009-12-28 20:11 UTC, Chris Cormack
Details

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


---- Reported by rch@liblime.com 2008-12-02 23:37:16 ----

Steps to reproduce:
  * Start with item Z, homebranch A, holdingbranch A.
  * Place a hold at branch B.
  * Check in the item at branch A.
  * Print slip & confirm to initiate the transfer.
  ** Check in the item AGAIN at branch A ( the item was perhaps not properly routed to the transfer shelf ).
  Result:
    * Three warning/confirmation dialogues,
    one warning that the item must be returned to the home location ( though it's already there)
    one offering to initiate the transfer to its home location ( in this case, incorrectly suggesting that the item's home location is branch B )
    one offering to initiate the transfer to fill the hold ( this is the only one that should appear).



---- Additional Comments From oleonard@myacpl.org 2009-04-24 15:46:39 ----

I think I've followed the steps described here, but I'm getting pretty much the opposite result: instead of three warning/confirmation dialogues I'm getting none.

What that means is that if I confirm a hold at Branch A that is to be transferred to another branch, checking it in again Branch A will not show me the hold notification message. It will appear as if the hold was canceled or never existed.



---- Additional Comments From nengard@gmail.com 2009-12-28 20:11:57 ----

Created an attachment
transit error wrong

I had an item in transit from CPL to LPL I then checked it in at CPL and got the message above which says to return the item to LPL.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:57 UTC  ---

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

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was rch@liblime.com.
CC member stevens@ci.salinas.ca.us does not have an account here
The original submitter of attachment 880 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2011-05-17 19:03:08 UTC
Sorry, I spoke too soon. I can't reproduce the bug as it is described in any of the comments here, but there is buggy behavior. Following the same steps:

Steps to reproduce:
  * Start with item Z, homebranch A, holdingbranch A.
  * Place a hold at branch B.
  * Check in the item at branch A.
  * Print slip & confirm to initiate the transfer.
  ** Check in the item AGAIN at branch A
     New result: Correct confirmation dialog is shown.
   ** Check in the item AGAIN at branch A
      New buggy behavior: NO confirmation dialog is shown.

You won't see this same behavior if the item is at Branch A for a patron at Branch A. The hold confirmation dialog is correctly shown on multiple check-ins.
Comment 2 Katrin Fischer 2019-05-04 18:38:47 UTC
Last comment is from 2011, probably needs to be re-tested first.
Comment 3 Nick Clemens 2022-09-02 05:36:59 UTC
Retested, I get the correct dialog to confirm and transfer / ignore every subsequent check in.

I think if there are still any bugs here, they should get a new report :-)