[Bug 14170] New: branchtransfers items need to be cancelled when on loan or a waiting reserve
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 Bug ID: 14170 Summary: branchtransfers items need to be cancelled when on loan or a waiting reserve Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: cbrannon@cdalibrary.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 --- Comment #1 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- No. I cannot tell exactly what causes it to be missed, but we are regularly seeing things like this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14170 Sally Healey <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org