---- Reported by nengard@gmail.com 2010-02-10 13:04:54 ---- Created an attachment search results with authors not in alpha order See the attached image. I ran an advanced search and chose to sort by Author A-Z and my results were not sorted. The other sorts seem to work A-OK - it's just this one that's not doing anything - or not doing what I'd expect. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:23 UTC --- This bug was previously known as _bug_ 4148 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4148 Imported an attachment (id=1873) Actual time not defined. Setting to 0.0 Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. The original submitter of attachment 1873 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
I think the problem may be that the sort is done on 100a, but the XSLT displays author information from other fields too. That means that if a record has, for instance, multiple authors under 700 but no 100, it will be sorted at the top because of "nothing comes before something." It's clearer if you have XSLT turned off because you can see the authors as "[empty] [empty] [empty] Akpan Alexie Anderson." Could that be it?
I still think the above explanation is correct. Does that make this bug invalid (since the search *is* sorting by author) or does that redefine the scope of the bug as "advanced search should include more than just 100a when sorting by author?"
I think the sort should look at other than 100a field for a sort on author.
If we include more than 100$a - how should we deal with multiple fields? 100$a and several 700...? Always use the first?
One of our new customers has reported this also. It is not just the case for the Advanced Search - quick search is the same. Both OPAC and staff.
(In reply to Fiona Borthwick from comment #5) > One of our new customers has reported this also. It is not just the case for > the Advanced Search - quick search is the same. Both OPAC and staff. It's certainly confusing for the patrons that an author A-Z search returns seemingly nonsensically sorted results first, but this bug isn't as simple as "fix sorting." Koha is sorting correctly, because "nothing comes before something." When sorting on 100a, results which have no 100a will be sorted first. Is it even possible for Zebra to create an index on "100a if present, 700a if not, but use the first 700a as sorted by first and second indicators?"
> Is it even possible for Zebra to create an index on "100a if present, 700a > if not, but use the first 700a as sorted by first and second indicators?" This seems awfully complicated. I wonder how other systems realize author sorting and if it is even offered?
Changed the bug description a little since we have concluded that it works ok. Thinking about it, maybe it should use 100, 110, 111, but I am not sure if using the 700 will not give even more confusing results unless we can limit to certain relator terms... and then it would require them to be catalogued correctly too. Maybe the safest bet would be to handle the 'no 1xx to sort' by sorting them to the end if possible?