Bug 6984 - Holds Statistics Doesn't Work
Summary: Holds Statistics Doesn't Work
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Reports (show other bugs)
Version: 3.6
Hardware: All All
: P5 - low critical (vote)
Assignee: Garry Collum
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-06 19:22 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
3 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 patch (12.26 KB, patch)
2012-02-01 15:39 UTC, Garry Collum
Details | Diff | Splinter Review
Bug 6984 - Holds statistics doesn't work. (12.40 KB, patch)
2012-02-02 05:35 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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.