Bug 3521

Summary: Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically
Product: Koha Reporter: Liz Rea <wizzyrea>
Component: TemplatesAssignee: 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:
Attachments: Proposed Patch
staff serial
staff monograph
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

---- 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

Comment 1 Nicole C. Engard 2011-05-11 20:13:29 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).

Comment 2 Ian Walls 2011-08-28 00:38:36 UTC Comment hidden (obsolete)
Comment 3 Nicole C. Engard 2011-08-28 13:01:42 UTC
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.
Comment 4 Nicole C. Engard 2011-08-28 13:02:10 UTC Comment hidden (obsolete)
Comment 5 Nicole C. Engard 2011-08-28 13:02:30 UTC Comment hidden (obsolete)
Comment 6 Paul Poulain 2011-09-27 15:33:18 UTC
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.
Comment 7 Ian Walls 2012-01-06 16:35:22 UTC
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)
Comment 8 Nicole C. Engard 2012-01-06 19:24:48 UTC Comment hidden (obsolete)
Comment 9 Nicole C. Engard 2012-01-06 19:25:13 UTC Comment hidden (obsolete)
Comment 10 Nicole C. Engard 2012-01-06 19:25:36 UTC Comment hidden (obsolete)
Comment 11 Nicole C. Engard 2012-01-06 19:30:35 UTC
This appears to be an issue with serials - monographs seem to be sorting right by branch, but the serials are not.
Comment 12 Nicole C. Engard 2012-01-06 19:36:11 UTC
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.
Comment 13 Nicole C. Engard 2012-01-06 19:37:52 UTC
Created attachment 7078 [details]

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.
Comment 14 Nicole C. Engard 2012-01-06 19:38:55 UTC
Created attachment 7079 [details]

Same deal here, plus it's not the same order that was in the staff client, but I don't know if that matters.
Comment 15 Kyle M Hall 2012-03-29 13:58:29 UTC Comment hidden (obsolete)
Comment 16 Kyle M Hall 2012-03-29 13:59:28 UTC Comment hidden (obsolete)
Comment 17 Liz Rea 2012-05-11 14:56:20 UTC
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.
Comment 18 Paul Poulain 2012-05-22 21:19:17 UTC
QA comment: one line patch that update SQL, passed QA
Comment 19 Chris Cormack 2012-05-23 22:25:46 UTC
Will be in 3.8.2