Bug 9091 - Error in logic CheckBorrowerDebarred
Summary: Error in logic CheckBorrowerDebarred
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-15 18:38 UTC by Jorge de Cardenas
Modified: 2014-12-07 20:03 UTC (History)
5 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 Jorge de Cardenas 2012-11-15 18:38:27 UTC
In Overdues.pm subroutine CheckBorrowerDebarred.

As far as I can tell debarred is 0 or 1 what is the purpose of testing against NOW()?

sub CheckBorrowerDebarred {
    my ($borrowernumber) = @_;
    my $dbh   = C4::Context->dbh;
    my $query = qq|
       SELECT debarred
       FROM borrowers
       WHERE borrowernumber=?
       AND debarred > NOW()  <==========??
    |;
    my $sth = $dbh->prepare($query);
    $sth->execute($borrowernumber);
    my $debarredstatus = $sth->fetchrow;
    return $debarredstatus;
}
Comment 1 Katrin Fischer 2012-11-16 08:10:22 UTC
debarred is now a date field in the database (connected to the fines in days feature) - which version are you looking at?
Comment 2 Fred P 2012-11-16 16:32:08 UTC
I believe this is a legacy data issue. New patrons are given a debarred date of 12-31-9999, debarred patrons are assigned a specific debarred date, while legacy patrons retain a [NULL] for debarred status in the borrowers table. 

Custom scripts will need to address these three possibilities.
Comment 3 Jorge de Cardenas 2012-11-19 14:15:48 UTC
(In reply to comment #1)
> debarred is now a date field in the database (connected to the fines in days
> feature) - which version are you looking at?

I have to systems running a test system which is 3.09.00.029 at a system I'm preparing to migrate our data into which is 3.09.00.059. On the .029 the database is still a tinyint for that field. It could have been that the database conversion failed. The .059 system has the correct datatype.