Bug 20947 - Navigating to moremember.pl for a patron who has fines on deleted items causes software error.
Summary: Navigating to moremember.pl for a patron who has fines on deleted items cau...
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 17.11
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-14 18:35 UTC by Barton Chittenden
Modified: 2019-10-14 19:56 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

Note You need to log in before you can comment on or make changes to this bug.
Description Barton Chittenden 2018-06-14 18:35:06 UTC
Note this ONLY happens in 17.11 -- earlier versions of Koha don't have this code, and GetMemberAccountRecords does not exist in 18.05+ (per bug 12001)... however it is a major problem in 17.11.

--

Steps to re-create:

1) Find a borrower with fines, preferably on an item that has already been checked in.
2) Delete the item
3) Navigate to moremember.pl for that borrower. This will trigger a software error with

Can't call method "biblio" on an undefined value at /usr/share/koha/lib/C4/Members.pm line 767.

in the plack-error.log

Here's the code:

 750 sub GetMemberAccountRecords {
 751     my ($borrowernumber) = @_;
 752     my $dbh = C4::Context->dbh;
 753     my @acctlines;
 754     my $numlines = 0;
 755     my $strsth      = qq(
 756                         SELECT *
 757                         FROM accountlines
 758                         WHERE borrowernumber=?);
 759     $strsth.=" ORDER BY accountlines_id desc";
 760     my $sth= $dbh->prepare( $strsth );
 761     $sth->execute( $borrowernumber );
 762 
 763     my $total = 0;
 764     while ( my $data = $sth->fetchrow_hashref ) {
 765         if ( $data->{itemnumber} ) {
 766             my $item = Koha::Items->find( $data->{itemnumber} );
 767             my $biblio = $item->biblio;

The problem is that $data->{itemnumber}, (the itemnumber read from accountlines) may point to an active item or a deleted item. If the item was deleted, $item, as populated in

   my $item = Koha::Items->find( $data->{itemnumber} );

will be undef, and 

   my $biblio = $item->biblio;

Will throw the error message.
Comment 1 Jonathan Druart 2018-06-14 19:28:39 UTC
I do not recreate, I noticed that accountlines.itemnumber is set to NULL when the item is deleted.
Can you detail a bit more the steps to recreate?
Comment 2 Barton Chittenden 2018-06-15 15:05:25 UTC
(In reply to Jonathan Druart from comment #1)
> I do not recreate, I noticed that accountlines.itemnumber is set to NULL
> when the item is deleted.
> Can you detail a bit more the steps to recreate?

The problem is triggered by accountlines records that have itemnumbers that don't point to items -- I honestly don't know *how* that happened -- manual database manipulation? Accountlines records that existed before the foreign key constraints?

I think as a work-around, we're going to simply null accountlines.itemnumber and set accountlines.note using

UPDATE
    accountlines
SET
    note=CONCAT(itemnumber," item deleted from system"),
    itemnumber=NULL
WHERE
    itemnumber NOT IN ( SELECT itemnumber FROM items );

I'm still open to a patch for this; but considering that the code that causes his no longer exists in master, and that I can't reproduce this by normal means in 17.11, I'm willing to use the workaround.
Comment 3 Jonathan Druart 2018-06-18 14:52:43 UTC
Could you confirm the FK is missing?
Comment 4 Nick Clemens (kidclamp) 2018-06-19 14:20:42 UTC
(In reply to Jonathan Druart from comment #3)
> Could you confirm the FK is missing?

Indeed, the foreign key appears to be missing on the affected site
Comment 5 Jonathan Druart 2018-06-19 14:28:45 UTC
It's not a new constraint, no idea how it could be possible.
Comment 6 Nick Clemens (kidclamp) 2018-06-19 15:55:26 UTC
(In reply to Jonathan Druart from comment #5)
> It's not a new constraint, no idea how it could be possible.

We suspect these sites were either original liblime dbs or created using outdated info.

Closing this bug out as it shouldn't occur without bad tables