[Koha-patches] [PATCH] Prevent fines failure on NULL borrowernumber.

[Kyle Hall]

Joe wrote:
> Upon
> checkin, none of these subsequent transactions are cleared either.  This
> means potentially many people get fined for the SAME item, that they already
> turned in, and they'll keep getting it no matter how many times the item is
> turned in!  This is very bad if you are running fines, hence the severity of
> my error message in the fines script.

Wouldn't generating fines upon an item's return circumvent this
problem? That's how our fines system works ( I submitted a patch for
FinesOnReturn a week or so ago ).

http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )




On Fri, Jan 23, 2009 at 10:04 PM, Joe Atzberger
<joe.atzberger at liblime.com> wrote:
> Michael --
>
> Thanks for the reply.  I think NULL borrowernumber in issues is in fact a
> mistake, broadly speaking.  You are correct that the design currently allows
> it, but it also falls apart after it is allowed.  I understand why we
> compromised at 3.0 release time, mainly to allow offline circ (and legacy
> code, perhaps dealing w/ lost items?) to work without failing, but I still
> regard it as inadvisable.
>
> Offline circ is a cool feature, but the checkout transaction in any ILS has
> as its most fundamental role to make a borrower responsible for an item.
> This mapping gets broken at a conceptual level if there is nobody
> responsible for the issue.  At a technical level, Koha's checkin doesn't
> work on NULL borrwernumber transactions.  What's worse, it allows additional
> transactions for the same item to be added to the issues table.  Upon
> checkin, none of these subsequent transactions are cleared either.  This
> means potentially many people get fined for the SAME item, that they already
> turned in, and they'll keep getting it no matter how many times the item is
> turned in!  This is very bad if you are running fines, hence the severity of
> my error message in the fines script.
>

>
> --Joe
>
> On Fri, Jan 23, 2009 at 6:02 PM, Michael Hafen <mdhafen at tech.washk12.org>
> wrote:
>>
>> I don't think it is a mistake that the borrowernumber in the issues
>> table can have NULL rows.  I do think that is is a bad thing though.
>> Looking at kohastructure.sql there is a Foreign Key Constraint that
>> states 'On Delete Set Null On Update Set Null'.
>>
>> I agree that this should not be. I think it would be better to state 'On
>> Delete Delete On Update Cascade' if possible.  That would be much
>> preferable in my opinion from a data integrity point of view.
>>
>> My point is that I think your error message below is a little misleading
>> given the foreign key constraint.
>>
>> Thanks for working on this problem though.  Have a nice day.
>>
>> On Fri, 2009-01-23 at 16:22 -0600, Joe Atzberger wrote:
>> > The problem is that we do not ensure that the issues table has valid
>> > borrowernumber in each line.  This is exacerbated by Getoverdues()
>> > returning data sorted BY borrowernumber.  So one NULL borrowernumber
>> > in issues prevented ALL fines from being assessed.  The actual error
>> > from fines.pl cron log is:
>> >   No branchcode argument to new.  Should be C4::Calendar->new(branchcode
>> > => $branchcode)
>> >   at /home/user/kohaclone/misc/cronjobs/fines.pl line 98
>> >
>> > This patch deals only with getting fines to avoid crashing.  It does
>> > not fix the underlying data integrity problem.
>> [snip]
>> > +        print STDERR "ERROR in Getoverdues line $i:
>> > issues.borrowernumber IS NULL.  Repair 'issues' table now!  Skipping
>> > record.\n";
>> > +        next;   # Note: this doesn't solve everything.  After NULL
>> > borrowernumber, multiple issues w/ real borrowernumbers can pile up.
>> > +    }
>> [snip]
>> --
>> Michael Hafen
>> Systems Analyst and Programmer
>> Washington County School District
>> Utah, USA
>>
>> for Koha checkout
>> http://koha-dev.washk12.org
>> or
>> git://koha-dev.washk12.org/koha
>>
>
>
> _______________________________________________
> Koha-patches mailing list
> Koha-patches at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-patches
>
>