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.
Created attachment 6264 [details] [review]
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.
Created attachment 6309 [details] [review]
Actually the original request was for the copy number, just wasn't formulated properly, and I copied it blindly. Serves me right.
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?
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?
Created attachment 6318 [details]
copy number blank
I think I figured out what's wrong (at least why I didn't see things). The Vol info looks like it might be in the call number column instead of the copy/vol column. If that's the way it's supposed to be just let me know. See attached.
See in the attached file that the copy number field has numbers for the first two, but the third actually has no copy number in the marc, but it does have an enumeration and that's not showing in that column, it looks like it might be in the call number column.
Created attachment 6319 [details]
here is the hold line on the bib record - showing the vol info is there.
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.
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.
That's fine, I can move it. Do you want to wait for some more comments first?
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?
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.
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 ;)
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.
Created attachment 7519 [details] [review]
I'm not sure why we placed enumchron next to the call number in the first place...
Created attachment 7535 [details] [review]
bug_7201: Holds reports: add copynumber and enumchron
Signed-off-by: Liz Rea <email@example.com>
Data is there and correct - very helpful patch, thanks!
passes prove t xt t/db_dependent in line with current master failures.
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.
patch pushed with a tiny follow-up fixing some indentation mistakes
This fix was included in the 3.6.x branch prior to 3.6.4.