Bug 14170 - branchtransfers items need to be cancelled when on loan or a waiting reserve
Summary: branchtransfers items need to be cancelled when on loan or a waiting reserve
Status: RESOLVED DUPLICATE of bug 24620
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 24620
  Show dependency treegraph
 
Reported: 2015-05-07 20:10 UTC by Christopher Brannon
Modified: 2021-03-16 11:13 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2015-05-07 20:10:00 UTC
Occasionally I find items in the branchtransfers that are still active while the item is on loan or a reserve waiting for pickup.  I've actually found one item that is waiting for a patron, but has TWO unfinished transfers!

Unless there is something I am missing, seems like it would be a good routine for Koha to check the branchtransfers table upon issue or being placed in a waiting status and cancel any pending transfers.

Christopher
Comment 1 Christopher Brannon 2015-05-07 20:40:07 UTC
Additionally, we still see remnants of incomplete transfers when the hold is triggered.  It would be nice if when a hold message is displayed upon check-in if it would go ahead and cancel any existing transfers, and not display the message.  I can't think of any good reason to keep an old transfer if the holds is triggering.  If the item has to be routed elsewhere, it would do so after triggering the hold.

Christopher
Comment 2 Christopher Brannon 2015-05-11 14:49:25 UTC
I'm wondering if this ticket should address a more pressing issue.  It is really perplexing as to why we are tracking the status of an item in 4 or more tables.  I can find the status of an item in the items, reserves, branchtransfers and issues tables, if not others.  This is extremely inefficient, and possibly the reason statuses get jumbled in Koha, I'm finding, on a regular basis.

Why not have an itemstatus table that keeps track of an item if it is not available?  The reserves table should really only keep track of who is next in the reserves.  On loan, waiting, transfers, and even damaged, lost, withdrawn, etc could all be tracked in one table.  You could even put the status of on cart for recently returned items in this table.

This is an area of Koha that could really use some attention and streamlining, in my opinion.  If I am wrong, that is fine.  I just think it should be discussed more.  It just seems like it could be a lot easier to troubleshoot and eliminate dual statuses.
Comment 3 Kyle M Hall 2015-05-11 16:35:08 UTC
It does appear that C4::Circulation::AddIssue closes out any open branch transfers at the time of checkin with the following query:

UPDATE branchtransfers SET datearrived = now(), tobranch = ?, comments = 'Forced branchtransfer' WHERE itemnumber= ? AND datearrived IS NULL

Where tobranch is the logged in branch.

Have you been able to trigger a scenario where the transfer isn't closed out when an item is issued?
Comment 4 Christopher Brannon 2015-05-11 16:55:17 UTC
No.  I cannot tell exactly what causes it to be missed, but we are regularly seeing things like this.
Comment 5 Kyle M Hall 2015-05-11 16:59:14 UTC
ModReserveStatus is only called by C4::Circulation::AddReturn, but any open branch transfers are closed out by the same code:

1918     if ($datesent) {
1919         if ( $tobranch eq $branch ) {
1920             my $sth = C4::Context->dbh->prepare(
1921                 "UPDATE branchtransfers SET datearrived = now() WHERE itemnumber= ? AND datearrived IS NULL"
1922             );
1923             $sth->execute( $item->{'itemnumber'} );
1924             # if we have a reservation with valid transfer, we can set it's status to 'W'
1925             ShelfToCart( $item->{'itemnumber'} ) if ( C4::Context->preference("ReturnToShelvingCart") );
1926             C4::Reserves::ModReserveStatus($item->{'itemnumber'}, 'W');
1927         } else {
1928             $messages->{'WrongTransfer'}     = $tobranch;
1929             $messages->{'WrongTransferItem'} = $item->{'itemnumber'};
1930         }
1931         $validTransfert = 1;
1932     } else {
1933         ShelfToCart( $item->{'itemnumber'} ) if ( C4::Context->preference("ReturnToShelvingCart") );
1934     }

ModReserveAffect should probably close out any open transfers in the case it's called to set an item to waiting.
Comment 6 Martin Renvoize 2021-03-15 17:09:27 UTC
This looks to be fixed with bug 24620 to me.. can you verify Christopher? (That bug has been pushed for 20.05.00 and 19.11.06)
Comment 7 Martin Renvoize 2021-03-15 17:09:57 UTC

*** This bug has been marked as a duplicate of bug 24620 ***