| Summary: | Incorrect sorting of call numbers in shelf browser | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Anke Bruns <anke.bruns> |
| Component: | OPAC | Assignee: | Owen Leonard <oleonard> |
| Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
| Severity: | minor | ||
| Priority: | P5 - low | ||
| Version: | 22.05 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Anke Bruns
2023-05-08 10:08:15 UTC
Just to check: does the sorting work ok for you in other places? For example the inventory list? You could also try a report like this: select cn_source, cn_sort, itemcallnumber from items order by cn_sort This should reflect how Koha thinks the callnumbers should be sorted. With the SQL query, I get results sorted in the same (numerically incorrect) way as described. I don't believe it's a bug then, it's a configuration issue. Koha will generate a sorting form of your callnumber (itemcallnumber) from the classification source (cn_source). It's saved to cn_sort and used in a lot of places for sorting callnumbers. If you check the manual for classification sources, you'll find information there about the 3 algorithms Koha has to do that (DDC, LOC and generic). Sadly no RVK and similar yet (I'd be happy to see that added :) ) |