Created attachment 34240 [details]
staff
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? Carnegie Team +1 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?) Test plan: You need to have different existing subscription, using different numbering. 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. Liz 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 - 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. Should we change this to 'Needs Signoff' to get some opinions? (In reply to Katrin Fischer from comment #21) > Should we change this to 'Needs Signoff' to get some opinions? Yes, done. Created attachment 97994 [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?) Test plan: You need to have different existing subscription, using different numbering. 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. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 97995 [details] [review] Bug 13420: Fallback to the previous behavior if published date is not used Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> This works as described and seems a suitable interim solution to me.. Signing off. Created attachment 98511 [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?) Test plan: You need to have different existing subscription, using different numbering. 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. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 98512 [details] [review] Bug 13420: Fallback to the previous behavior if published date is not used Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 98513 [details] [review] Bug 13420: (QA follow-up): Fix typo itemdate -> itemdata Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Nice work everyone! Pushed to master for 20.05 Pushed to 19.11.x for 19.11.04 backported to 19.05.x for 19.05.09 |
Created attachment 34239 [details] opac 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