Bug 6984

Summary: Holds Statistics Doesn't Work
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: ReportsAssignee: Garry Collum <gcollum>
Status: CLOSED FIXED QA Contact: Bugs List <koha-bugs>
Severity: critical    
Priority: P5 - low CC: koha.sekjal, paul.poulain, wizzyrea
Version: 3.6   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Proposed patch
Bug 6984 - Holds statistics doesn't work.

Description Nicole C. Engard 2011-10-06 19:22:52 UTC
The subject says it all. I tested this on 3.4 and on master (and on multiple libraries) and it just never gives you results no matter what combo you try.
Comment 1 Paul Poulain 2011-10-26 14:47:12 UTC
Still valid in 3.6

There is an SQL error in the logs :
[Wed Oct 26 16:46:07 2011] reserves_stats.pl: DBD::mysql::st execute failed: Unknown column 'holdingbranch' in 'where clause' at /home/paul/koha.dev/koha-community/reports/reserves_stats.pl line 274.
[Wed Oct 26 16:46:07 2011] reserves_stats.pl: DBD::mysql::st fetchall_hashref failed: statement contains no result [err was 4 now 2000000000]
[Wed Oct 26 16:46:07 2011] reserves_stats.pl: Field 'line' does not exist (not one of ) at /home/paul/koha.dev/koha-community/reports/reserves_stats.pl line 276.
Comment 2 Garry Collum 2012-02-01 15:39:14 UTC Comment hidden (obsolete)
Comment 3 Liz Rea 2012-02-02 05:35:27 UTC
Created attachment 7420 [details] [review]
Bug 6984 - Holds statistics doesn't work.

This patch fixes several errors in reserves_stats.pl and reserves_stats.tt.

Testing -
To test this patch, data must be in either the reserves table or old_reserves or both.  The following SQL will give you the raw data that is used by the report.

SELECT priority, found, reservedate, notificationdate, reminderdate,
waitingdate, cancellationdate, borrowers.categorycode, items.itype,
reserves.branchcode, holdingbranch, items.homebranch, items.ccode,
items.location, items.itemcallnumber, borrowers.sort1, borrowers.sort2
FROM reserves
LEFT JOIN borrowers on (borrowers.borrowernumber = reserves.borrowernumber)
LEFT JOIN items on (items.itemnumber = reserves.itemnumber)
UNION SELECT priority, found, reservedate, notificationdate, reminderdate,
waitingdate, cancellationdate, borrowers.categorycode, items.itype,
old_reserves.branchcode, holdingbranch, items.homebranch, items.ccode,
items.location, items.itemcallnumber, borrowers.sort1, borrowers.sort2
FROM old_reserves
LEFT JOIN borrowers on (borrowers.borrowernumber = old_reserves.borrowernumber)
LEFT JOIN items on (items.itemnumber = old_reserves.itemnumber)

To test the notificationdate and reminderdate, I added data to the old_reserves table, since I have never run notices on my test machine.

Ex:
UPDATE old_reserves
SET notificationdate = "2012-01-29",
reminderdate = "2012-01-29"
WHERE timestamp = "2012-01-29 20:09:34";

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Confirm original bug -- Reports work as expected now!
prove t xt t/db_dependent no different from master.
Comment 4 Ian Walls 2012-02-03 12:41:34 UTC
Mostly cleans up T:T scope and spacing/layout in Perl.  Adds an additional elsif for exclusive less than, and changes how a few variables are referenced (hash v. hashref).

All in all, this improves coding style, and doesn't touch any core C4 modules, so tests should all be safe and the same.  Marking as Passed QA.
Comment 5 Jared Camins-Esakov 2012-05-23 12:58:42 UTC
This fix was included in the 3.6.x branch prior to 3.6.4.