Created attachment 34239 [details]
See attached. In the staff client and OPAC when you short on volume things are not sorted the way the user would expect. 19 is coming after 160
Created attachment 34240 [details]
How do I reproduce this? Is it still valid?
*** This bug has been marked as a duplicate of bug 12375 ***
This is still valid.
Can you do a screenshot of the full page please so I can see where this is and how to reproduce it
Created attachment 47566 [details]
Screenshot of bug in context in the staff view
While the duplicate bug has been marked as fixed, I am not entirely clear on if that bug will address this issue, so I will update this ticket. Attached is a screenshot of the bug in context in the staff view. The OPAC view sorts in a similar way.
This issue is that the volume column is being sorted as a string, rather than a number. This does and does not make sense. The volume field is not strictly a number, but is a general text field. Some libraries may put "123" in there, or "vol 123" or as is the case for Karl, "v. 123".
The quick hack solution would be to pad out all the volume numbers to the same length in the volume field itself. This is a very sub-optimal solution.
I think the optimal solution would be to take each volume field and pad out each number in the string to 10 or so digits. We can then take the padded version and put it in a hidden column that is used for sorting the visible column.
The regex s/([0-9]+)/sprintf('%010d',$1)/ge; should take care of the padding.
Another option, considering this is a serials column, would be to use the serial sequence columns x y and x directly, instead of the concatenated version. The need for padding would still apply though.
I'd think the most desirable solution would be use padded X Y and Z columns on the backend to conduct the sort, and have the nicely formatted version display.
This is a pet peeve of mine. If a missed serial is donated at a later date, I never get to see my serials in sequential order, because sorting by Vol replicates what is seen above, while sorting by call number alphabetizes them so all Aprils (regardless of year) are before all the Novembers. The only way they are in order is if my barcodes are in order; that only happens if no issues are missed or go walking.
Any more progress?
Would it make sense to sort by published dates?
We would be interested in a sort by published date as we do not enter volumes or issues as finding that information too way to long for our staff. Fewer items are claimed these days and very few people ever come to us looking for a specific volume/issue of a periodical.
Created attachment 88995 [details] [review]
Bug 13420: Sort "Serial enumeration" by published date
So far the sorting on volume information is incorrect. It sorts by the
string displayed in the cell, which may not have any logics.
A better solution would be to use Kyle's suggestion, see comments 7, 8,
but it will need much more work.
This patch suggests to use the publication date to sort this column.
Note: In the code there is a switch depending on the existence of
items.publisheddate, but I do not think it is valid, this valid should
always exist if the item is received (did I miss something?)
You need to have different existing subscription, using different
On the detail page of the bibliographic record you should be able to
sort the serials (tab "Holdings") by "Serial enumeration".
The sort will now use the publication dates.
Libraries not using the serials module still use the enumchron fields. So a fallback to the current behaviour is needed, even if not perfect.
This is actually a really hard bug to fix because that field isn't uniform across libraries, and it's human input (sometimes) as well. It can be just numeric, alphanumeric, or only words.
I don't know how you even could universally fix this sorting problem, short of making it so people could choose the type of sort they want on the column.
I like the idea of a configurable sort for now with the option to add a more complicated fix using the serial pattern variables later on.
- publicationdate with fallback to alphabetic if empty
- strictly alphabetic
Created attachment 92026 [details] [review]
Bug 13420: Fallback to the previous behavior if published date is not used
(In reply to Katrin Fischer from comment #18)
> I like the idea of a configurable sort for now with the option to add a more
> complicated fix using the serial pattern variables later on.
> So maybe:
> - publicationdate with fallback to alphabetic if empty
The last patch implements that suggestion.