---- Reported by mcoalwell@nekls.org 2009-08-17 15:57:08 ---- Regardless of how many times an item is Checked In, if the Check In occurs at a library other than the target library, then a transfer prompt should appear, every time, to instruct the staff person to transfer the item to the target library. It doesn't make any sense for the prompt to appear once, and only once. Koha needs to show a message when: currentlocation != homebranch and status = available. ---- Additional Comments From smoreland@nekls.org 2009-08-17 16:21:39 ---- This bug goes with 3298, an enhancement request for a "check item status" function that is more benign than the Check In function. A Scenario: An item belonging to Library A is returned to Library B after being checked out to a patron from Library B and the staff at Library B fail to see the transit prompt and accidentally reshelve the item. The item is later found. A staff member from Library B scans the barcode using the Check In function. Koha 'clears' the transit and changes the current location from Library A to Library B, rather than displaying the transit prompt again. With Koha is it works now, the staff member should have searched for the item via a catalog search, then referred to the holdings table to see the status of the item. In our consortium, the current location and homebranch should only mis-match if an item is: in transit to a location to fill a hold, on the holds shelf for a patron, or checked out. I would argue that an item in transit to a location to fill a hold should NOT have a status of 'available', but that's a different enhancement request, I suppose. ---- Additional Comments From mcoalwell@nekls.org 2009-08-17 16:34:18 ---- Created an attachment Showing On Hold Items on Search Results ---- Additional Comments From mcoalwell@nekls.org 2009-08-17 16:35:06 ---- There is a crucial piece to addressing this scenario that Dan Sweeney spec'd for us before he left, and it concerns the creation of a new “On Hold” group that will indicate what items are on hold. These items will not be counted as “Available.” Additionally, for items in transit, a new “In transit” display status has been added recently. This shows on both the search results screen and the record details screen. Items that are in transit do not count as available. This change has not been delivered to customers yet. [as of 8/13/09]. I'm attaching the entire spec for anyone interested. ---- Additional Comments From oleonard@myacpl.org 2009-12-22 17:48:50 ---- This is not an enhancement, this is a requirement! If I have an item from Library A and I check it in at Library B, I should be prompted to return it to Library A whether or not the item was checked out. This is broken--I get no prompt. ---- Additional Comments From oleonard@myacpl.org 2009-12-22 19:31:07 ---- Some notes for chris: http://paste.workbuffer.org/98 ----------------------------- 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1460) $doreturn = 0; 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1461) # bailing out here - in this case, current desired 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1462) # is to act as if no return ever happened at all. 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1463) # FIXME - even in an indy branches situation, there 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1464) # still be an option for the library to accept the 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1465) # and transfer it to its owning library. 5593a281 (Galen Charlton 2009-08-23 10:01:19 -0400 1466) return ( $doreturn, $messages, $issue, $borrower ); http://paste.workbuffer.org/99 ----------------------------- if ($doreturn and ($branch ne $hbr) and not $messages->{'WrongTransfer'} and ($validTransfert ne 1) ){ if ( C4::Context->preference("AutomaticItemReturn" ) or (C4::Context->preference("UseBranchTransferLimits") and ! IsBranchTransferAllowed($branch, $hbr, $item->{C4::Context->preference("BranchTransferLimitsType")} ) )) { $debug and warn sprintf "about to call ModItemTransfer(%s, %s, %s)", $item->{'itemnumber'},$branch, $hbr; $debug and warn "item: " . Dumper($item); ModItemTransfer($item->{'itemnumber'}, $branch, $hbr); $messages->{'WasTransfered'} = 1; } else { $messages->{'NeedsTransfer'} = 1; # TODO: instead of 1, specify branchcode that the transfer SHOULD go to, $i$ } } http://paste.workbuffer.org/100 ----------------------------- if ($issue and $issue->{borrowernumber}) { $borrower = C4::Members::GetMemberDetails($issue->{borrowernumber}) or die "Data inconsistency: barcode $barcode (itemnumber:$itemnumber) claims to be issued to non-existant borro$ . Dumper($issue) . "\n"; } else { $messages->{'NotIssued'} = $barcode; # even though item is not on loan, it may still be transferred; therefore, get current branch info $doreturn = 0; # No issue, no borrowernumber. ONLY if $doreturn, *might* you have a $borrower later. } ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-23 01:11:49 ---- Further investigation We have discovered the culprit. my $hbr = $item->{C4::Context->preference("HomeOrHoldingBranch")} || ''; So if you have HoldingBranch set .. then it won't attempt a transfer back to the items homebranch, but to its holdingbranch instead. Which I don't think is the intended behaviour. This overrides the syspref to do automatic transfer to homebranch. I think $hbr should always get the value of the items homebranch. This plus the other error (the fact a transfer is only done if an item is returned) cause the behaviour. I can send a patch to fix, but I'd like some agreement that checking the items homebranch is the right thing to do when working out if a transfer is needed. ---- Additional Comments From nahuel.angelinetti@biblibre.com 2009-12-23 08:55:50 ---- I'll do a patch for this, a new syspref will be available for returns: HomeOrholdingbranchReturn The updatedatabase will copy the HomeOrholdingbranch in the new one. ---- Additional Comments From nahuel.angelinetti@biblibre.com 2009-12-23 14:53:19 ---- Created an attachment bugfix ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-26 08:44:42 ---- Patch reformatted and sent for master also ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-26 08:45:38 ---- Created an attachment Patch for bugfix on master branch ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-26 08:51:55 ---- Created an attachment Patch for master --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:11 UTC --- This bug was previously known as _bug_ 3536 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3536 Imported an attachment (id=1398) Imported an attachment (id=1399) Imported an attachment (id=1400) Imported an attachment (id=1401) Actual time not defined. Setting to 0.0 The original submitter of attachment 1398 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 1399 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 1400 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 1401 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Patch hasn't been pushed yet. Will follow up with Galen
Checking in on the status of this patch
Updating version as described in http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_July_2010
Sharon Moreland at NEKLS reports similar problems with these circumstances: When an item belonging to Library A is returned at Library B, a transfer prompt is displayed ONLY when that item is being checked in after issue. A transfer prompt does NOT display in these other instances where currentlocation != homebranch: 1. When an item arrives at Library to fill a hold that has been canceled (bug 3270) 2. When an item marked LOST or CLAIMS RETURNED is checked in (after being found). 3. When an item that is not checked out (taken without being checked out or reshelved after transfer prompt overlooked) is checked in System preferences settings: AutomaticItemReturn is ON and HomeOrHoldingBranch is 'holding branch' ----- sekjal did extensive testing on the IRC today (see the logs) with the proposed patch, and it does not seem to fix all the problems. I am wondering if the simpler fix wouldn't be to make the checkin code obey the AutomaticItemReturn in cases where the item is not presently checked out. Haven't dug into the code yet myself to check this as an option.
Testing the patch as applied to the bug_3536_holeorholdbranchreturn branch at http://git.librarypolice.com/?p=koha-rm.git;a=summary: Using both a book and a patron from Library A With HomeOrHoldingBranchReturn = 'homebranch': checkout A, return B => transfer message, B -> A checkout B, return B => transfer message, B -> A checkout B, return A => no message this seems to be desirable behaviour With HomeOrHoldingBranchReturn = 'holdingbranch': checkout A, return B => transfer message, B -> A checkout B, return B => no message checkout B, return A => first a transfer message B -> A (which marks the item as in transit A -> B) ...upon second return to A => a transfer message, A -> B. In transit message stays the same ...upon third return to B => no message, item rests with homebranch = A and holdingbranch = B If the first transfer message were removed from the final case, this would seem to be desirable behaviour Testing did not show any effect from HomeOrHoldingBranch's value. Testing did not factor in the AutomaticItemReturn system preference, was set to 'Do' for all tests.
Created attachment 2615 [details] [review] Modified patch, signed off This version of the patch adds support in circ/returns.pl for return branches other than Homebranch. Before, if a transfer was required, the message displayed would always indicate the items should be transferred to it's Homebranch, even if HomeOrHoldingBranchReturn was set to 'holdingbranch'
Created attachment 2616 [details] [review] revised patch, improved formatting Previous submission may not have been in a desirable format for application; reattaching.
Patch pushed to HEAD for inclusion in 3.2. Leaving bug open but downgrading priority because of minor cosmetic change need to add to circulation.pref.
This preference is in the local use tab and not where it belongs.
Whats the current status of this?
Marking fixed because in my tests an item belonging to another branch will trigger the "Please return to..." message when checked in even if it is not checked out.