Summary: | Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically | ||
---|---|---|---|
Product: | Koha | Reporter: | Liz Rea <wizzyrea> |
Component: | Templates | Assignee: | Ian Walls <koha.sekjal> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | trivial | ||
Priority: | P3 | CC: | chris, dschust1, koha.sekjal, kyle.m.hall, nengard, paul.poulain, smoreland, wizzyrea |
Version: | 3.8 | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Proposed Patch
opac staff opac staff serial staff monograph staff opac Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically |
Description
Chris Cormack
2010-05-21 01:11:41 UTC
Changing this to being assigned to Owen since it seems like a template issue to me and he added a table sorter for me easy peasy a week or two ago :) Also, I don't see any patches or fixes for this, so I don't think it's being worked on anymore (if it is feel free to correct me). Nicole Created attachment 5180 [details] [review] Proposed Patch Proposed Patch: changes GetItemsInfo sort from branch then dateaccessioned to branch, enumchron, copynumber, dateaccessioned. This puts keeps items grouped by branchcode first, then ordered by volume/issue (if applicable), then ordered by copy number (if applicable), then ordered by dateaccessioned. I tested this but it doesn't seem to do what it says it will do. See attached images. * In the staff client there still appears to be no order. * In the opac it is clumping together by branch but it's not by volume information as you stated. Created attachment 5182 [details]
opac
* In the opac it is clumping together by branch but it's not by volume information as you stated.
Created attachment 5183 [details]
staff
* In the staff client there still appears to be no order.
I was wondering if the best order would not be homebranch, location, callnumber, enumchron, copynumber, dateaccessioned Aren't there cases where it's usefull to have location & callnumber ? Usually, all issues of a given biblio are all stored at the same location/callnumber, so that won't make a difference, but for non serials, there would be. I agree with Nicole the results are not properly sorted though. Grouping by Branch is pretty solidly required. Whether that's home or holding branch is outside the scope of this fix. I'm not sure location and callnumber are appropriate for sorting; I see that more as incidental information, rather than 'scanning' information. When confronted with a long list of results (which usually happens if there are multiple volumes or other enumchron data), I would first scan for the volume/issue I want, then see where to go to get it (location and callnumber). I think that's the standard behaviour for patrons, but I could be mistaken. Nicole, I'm not seeing the problems you are, so I think this must be a data issue. Can you compare before and after this patch, and see if things are any worse for you? Because I'm getting a definite improvement on my test system, and if it's not causing any more of a problem, this may be a benign enough change to push (it's just a modification to the ORDER BY clause, after all) Created attachment 7075 [details]
opac
I see no difference - this is still not sorting right - this is the OPAC
Created attachment 7076 [details]
staff serial
no sorting here either
Created attachment 7077 [details]
staff monograph
no sorting here either
This appears to be an issue with serials - monographs seem to be sorting right by branch, but the serials are not. I'm sorry, I thought we were talking about sorting by branch - which is another bug report. Let me test with the sorting my vol num field. Created attachment 7078 [details]
staff
Vol 1 is coming before 10 and 9 is coming after 10 - so it's not sorting right by librarian terms, but is sorting as a computer would sort it, so I don't now what the goal is here.
Created attachment 7079 [details]
opac
Same deal here, plus it's not the same order that was in the staff client, but I don't know if that matters.
Created attachment 8688 [details] [review] Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Based on patch submitted by Ian Walls Items were sorted by branch, then date accessioned, in GetItemsInfo. While this can be helpful in some circumstances, more often it is useful for items to be sorted first by their enumchron (volume/issue, if applicable) then by their copy number. This patch changes the sort on GetItemsInfo to branch, enumcrhon, copynumber then date accessioned. As sorting on copynumber will be incorrect based on standard sorting ( e.g. 1, 10, 2, 20 ), the copynumber is now padded with leading zeros to correct the sorting ( e.g. 01, 02, 10 20 ). This function appears to be a standard SQL function and not a mysql-ism. I have verfified that is available in MySQL, Postgres, and Oracle. Created attachment 8689 [details] [review] Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Based on patch submitted by Ian Walls Items were sorted by branch, then date accessioned, in GetItemsInfo. While this can be helpful in some circumstances, more often it is useful for items to be sorted first by their enumchron (volume/issue, if applicable) then by their copy number. This patch changes the sort on GetItemsInfo to branch, enumcrhon, copynumber then date accessioned. As sorting on copynumber will be incorrect based on standard sorting ( e.g. 1, 10, 2, 20 ), the copynumber is now padded with leading zeros to correct the sorting ( e.g. 01, 02, 10 20 ). This function appears to be a standard SQL function and not a mysql-ism. I have verfified that is available in MySQL, Postgres, and Oracle. Created attachment 9520 [details] [review] Bug 3521 - Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically Based on patch submitted by Ian Walls Items were sorted by branch, then date accessioned, in GetItemsInfo. While this can be helpful in some circumstances, more often it is useful for items to be sorted first by their enumchron (volume/issue, if applicable) then by their copy number. This patch changes the sort on GetItemsInfo to branch, enumcrhon, copynumber then date accessioned. As sorting on copynumber will be incorrect based on standard sorting ( e.g. 1, 10, 2, 20 ), the copynumber is now padded with leading zeros to correct the sorting ( e.g. 01, 02, 10 20 ). This function appears to be a standard SQL function and not a mysql-ism. I have verfified that is available in MySQL, Postgres, and Oracle. Signed-off-by: Liz Rea <wizzyrea@gmail.com> Passed t xt Item sorts appear to be correct to me based on the rubric of branch, enumchron, copynumber, then date accessioned. QA comment: one line patch that update SQL, passed QA Will be in 3.8.2 |