Bug 7201 - Hold to pull report needs extra fields
Summary: Hold to pull report needs extra fields
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: 3.6
Hardware: All All
: P3 enhancement (vote)
Assignee: Srdjan Jankovic
QA Contact: Ian Walls
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-09 07:05 UTC by Srdjan Jankovic
Modified: 2013-12-05 19:57 UTC (History)
4 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (7.74 KB, patch)
2011-11-09 07:34 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (9.02 KB, patch)
2011-11-15 03:04 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
copy number blank (66.60 KB, image/png)
2011-11-16 15:38 UTC, Nicole C. Engard
Details
hold (20.87 KB, image/png)
2011-11-16 15:39 UTC, Nicole C. Engard
Details
patch (8.92 KB, patch)
2012-02-09 00:33 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
bug_7201: Holds reports: add copynumber and enumchron (9.12 KB, patch)
2012-02-09 15:50 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 Srdjan Jankovic 2011-11-09 07:05:59 UTC
Currently when a periodical has been requested no indication is given of what issue the patron wants.

Could you please make it so that the vol field displays, and also the location.

In many respects the ' Holds awaiting pickup' is perfect, except for the vol field which is missing there too.
Comment 1 Srdjan Jankovic 2011-11-09 07:34:27 UTC Comment hidden (obsolete)
Comment 2 Nicole C. Engard 2011-11-11 15:58:14 UTC
The copy number is showing, not the volume number field.  952$h is serial enumeration/volume and 952$t is copy number.  I'm not sure if we want both to show - but we certainly want $h to show which is what the original request was for.

Nicole
Comment 3 Srdjan Jankovic 2011-11-15 03:04:35 UTC Comment hidden (obsolete)
Comment 4 Srdjan Jankovic 2011-11-15 03:06:47 UTC
Actually the original request was for the copy number, just wasn't formulated properly, and I copied it blindly. Serves me right.
Comment 5 Nicole C. Engard 2011-11-16 05:38:16 UTC
Srdjan,

Does that mean your new patch should show the enumeration/volume? Cause I'm still not seeing it.

Is there a test plan for this patch?

Nicole
Comment 6 Srdjan Jankovic 2011-11-16 06:46:51 UTC
Yes, it should show enumeration/volume together with hold number, if enumeration/volume exists on "Holds to Pull" (circ/pendingreserves.pl), "Holds Queue" (circ/view_holdsqueue.pl) and "Holds awaiting pickup" (circ/waitingreserves.pl) reports. As well as copy number.
There's no test plan, just confirmation new fields are visible and no issues introduced.
Can you please tell us where is enumeration/volume missing?
Comment 7 Nicole C. Engard 2011-11-16 15:38:55 UTC Comment hidden (obsolete)
Comment 8 Nicole C. Engard 2011-11-16 15:39:24 UTC Comment hidden (obsolete)
Comment 9 Srdjan Jankovic 2011-11-16 23:07:26 UTC
I'm not sure whether it is supposed to be like that, it was suggested to put it there. I'm just a developer :) I do vaguely remember though that we put it in the same place elsewhere in the system. If you think it is confusing, or there's a better way of displaying it I'm happy to move it, that is not a big deal.
Comment 10 Gaetan Boisson 2012-02-03 14:39:54 UTC
Just tested. The patch works as expected, that is that the volume information is displayed in the callnumber column. I would think it makes more sense to have it in the copynumber column.
Comment 11 Srdjan Jankovic 2012-02-06 00:52:47 UTC
That's fine, I can move it. Do you want to wait for some more comments first?
Comment 12 Gaetan Boisson 2012-02-06 08:32:27 UTC
I would rather see it in the copynumber column indeed, because the call number could be the same for different issues of the same serial, which could make things confusing. Also i have rarely seen copynumber used so far.

More input would definitely be nice though!

Nicole what do you think is best?
Comment 13 Nicole C. Engard 2012-02-08 11:46:41 UTC
I would say that it doesn't belong in the call number column either, but copy number and serial enumeration are two different things. I think if it goes in to the copy number column then the column should be relabeled as 'Copy No/Enumeration' so that people are clear that it's showing two fields of data. Or it should go in to a new column altogether.

Nicole
Comment 14 Gaetan Boisson 2012-02-08 12:17:49 UTC
Thanks for your input Nicole.
Creating a new column could be the best option here imho. But having copynumber renamed to copynumber/enumeration would be perfectly fine with me and probably much easier to implement.

Srdjan, you decide i guess ;)
Comment 15 Srdjan Jankovic 2012-02-08 23:24:53 UTC
It will take me a couple of years to understand the business enough to make competent decisions, but usually i go for the best if I can, so new column it will be.
Comment 16 Srdjan Jankovic 2012-02-09 00:33:21 UTC Comment hidden (obsolete)
Comment 17 Liz Rea 2012-02-09 15:50:16 UTC
Created attachment 7535 [details] [review]
bug_7201: Holds reports: add copynumber and enumchron

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Data is there and correct - very helpful patch, thanks!
passes prove t xt t/db_dependent in line with current master failures.
Comment 18 Ian Walls 2012-02-16 16:50:04 UTC
I would argue that enumerated chronology and copynumber could live happily in a single column, as they are usually exclusive (books tend to have multiple copies, serials tend to have vol/issues).  Having both columns will likely create some unused space in the report, but that's an aesthetics issue to be resolved in a subsequent patch.  The functionality here looks good, and passes QA.
Comment 19 Paul Poulain 2012-02-17 09:58:41 UTC
patch pushed with a tiny follow-up fixing some indentation mistakes
Comment 20 Jared Camins-Esakov 2012-05-23 13:02:46 UTC
This fix was included in the 3.6.x branch prior to 3.6.4.