Bug 2975 - Offline circ tries to circ on biblio-level "itemtype"
Summary: Offline circ tries to circ on biblio-level "itemtype"
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: PC All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
: 5802 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-20 11:53 UTC by Chris Cormack
Modified: 2019-06-27 09:24 UTC (History)
4 users (show)

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


Attachments
proposed bugfix (4.18 KB, patch)
2011-03-03 19:55 UTC, Galen Charlton
Details | Diff | Splinter Review
whitespace cleanup; no functional effect (13.93 KB, patch)
2011-03-03 19:55 UTC, Galen Charlton
Details | Diff | Splinter Review

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


---- Reported by joe.atzberger@liblime.com 2009-02-20 11:53:11 ----

Offline circ is confused about retrieving the issuing rule.

The code at lines 240-246 is:

  my $branchcode = C4::Context->userenv->{branch};
  my $borrower = GetMember( $circ->{ 'cardnumber' }, 'cardnumber' );
  my $item = GetBiblioFromItemNumber( undef, $circ->{ 'barcode' } );
  my $issue = GetItemIssue( $item->{'itemnumber'} );

  my $issuingrule = GetIssuingRule( $borrower->{ 'categorycode' }, $item->{ 'itemtype' }, $branchcode );


Note that $item is actually a biblio!  So this is a problem for GetIssuingRule, since the biblio level data may not correspond to the correct circ rule for the itype, or to any circ rule at all.  In at least one client's case, biblio.itemtype is routinely undefined.

The result is to fallback to the default rule.  If no default rule is defined, the circ period is effectively ZERO days, meaning the book is checked out, but DUE TODAY.  (This was the symptom reported by our client.)  The workaround is to define a default rule that will catch most of the cases.

I believe offline circ is the last part of Koha that has not been adapted to circ on items.itype.  It should be brought up to date and the variable names fixed for clarity.  

Here's the command line test (w/ proper ENV variables set) that I used to replicate what the above lines are doing, showing the empty itemtype.

perl -e 'use C4::Biblio; use C4::Members; use C4::Circulation; $b=GetMember(29301000242809, "cardnumber"); 
print "cardnumber and categorycode: ", $b->{cardnumber}, " ", $b->{categorycode}, "\n"; 
$biblio=GetBiblioFromItemNumber( undef,39301001819082); 
print "biblio: ", $biblio->{biblionumber}, " ", $biblio->{title}, "\n"; 
print "itemtype: ", $biblio->{itemtype}, "\n"; $rule=GetIssuingRule($b->{categorycode}, $biblio->{itemtype}); '

Outputs:
cardnumber and categorycode: 29301000242809 RES
biblio: 53498 AVP
itemtype: 

Please consider fixing this with the NULL borrowernumber in issues problem at the same time.



---- Additional Comments From drdrulm@yahoo.com 2009-11-04 17:36:38 ----

NULL borrowernumber is Not Good

If a patron barcode is misread by a barcode scanner, then the borrowernumber will default to NULL. 

Even worse, the item cannot be checked in! And any others who check out the item also cannot check the item back in, and thus creates a chain of items that cannot be checked in until the issues with the NULL borrowernumbers are deleted (manually, there is no other way to do it). 

This is a critical. 

-Darrell Ulm



---- Additional Comments From drdrulm@yahoo.com 2009-11-18 20:25:23 ----

I repaired the additional crit problem if the barcodes do not scan correctly or are entered incorrectly. Also patch sent outputs more information when processing. 

Darrell Ulm



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:04 UTC  ---

This bug was previously known as _bug_ 2975 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2975

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 joe.atzberger@liblime.com.
CC member arm@hanover.ca does not have an account here
CC member bchurch@ptfs.com does not have an account here
CC member drdrulm@yahoo.com does not have an account here
CC member emily.funk@liblime.com does not have an account here

Comment 1 Marcel de Rooy 2011-01-31 09:20:15 UTC
Cannot test the patch: cannot find it. It would be handy to include the patch as an attachment to the bug report. Or at least a link to patches archive.

Since the report now obfuscates the signoff list, I have changed the patch status.
Comment 2 Galen Charlton 2011-03-03 16:51:03 UTC
Taking this on, to handle both the null borrowernumber issue as well as the incorrect calculation of due dates.
Comment 3 Galen Charlton 2011-03-03 19:55:21 UTC
Created attachment 3243 [details] [review]
proposed bugfix
Comment 4 Galen Charlton 2011-03-03 19:55:48 UTC
Created attachment 3244 [details] [review]
whitespace cleanup; no functional effect
Comment 5 Chris Cormack 2011-03-07 01:36:34 UTC
Pushed, please test and mark resolved
Comment 6 Ian Walls 2011-03-07 14:58:16 UTC
*** Bug 5802 has been marked as a duplicate of this bug. ***