---- Reported by wizzyrea@gmail.com 2009-08-11 15:27:15 ---- The items in the table for catalogue/detail.pl and cataloguing/additem.pl are sorted by database addition date. This is nonsensical in large consortia/migrated systems. There are a couple of different ways to handle this: 1. Sort by logged in user branch first (makes most sense to us) 1a. There has been some discussion of "sort by logged in user" as a system preference across the board for all places such a sort would make things easier (adding patrons, etc). 1b. It would be nice if it sorted by logged in user, then by acquisition date, not date item added to the database. In migrated collections, database add date is always the date of migration into the system, and this results in a nonsensical display. 2. Add a tablesorter or some other jquery hackery to sort by any column. Other solutions and comments are welcome. ---- Additional Comments From chris@bigballofwax.co.nz 2009-08-11 21:20:03 ---- Working on 1 (a and b) now. The syspref will default to off, so default behaviour won't change for anyone, but if you switch it on, then it will use the rules in 1b to sort. I think 2 is still desirable and will look into that after ---- Additional Comments From chris@bigballofwax.co.nz 2009-08-11 21:29:30 ---- After chatting with Liz, for sorting by items we will use the items homebranch. ---- Additional Comments From dschust1@gmail.com 2009-09-17 15:28:55 ---- (In reply to comment #2) > After chatting with Liz, for sorting by items we will use the items homebranch. > this is what I was looking for great! --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:11 UTC --- This bug was previously known as _bug_ 3521 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3521 Actual time not defined. Setting to 0.0
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