Summary: | branchtransfers items need to be cancelled when on loan or a waiting reserve | ||
---|---|---|---|
Product: | Koha | Reporter: | Christopher Brannon <cbrannon> |
Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | baselibrary.consortium, gmcharlt, josef.moravec, kyle.m.hall, kyle, martin.renvoize, sally.healey |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 24620 |
Description
Christopher Brannon
2015-05-07 20:10:00 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 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. 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? No. I cannot tell exactly what causes it to be missed, but we are regularly seeing things like this. 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. 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) |