This is difficult to explain and replicate. So these are the steps taken and results. 1. Create a custom classification source with code "boyden" with dewey filing rule and dewey splitting rule. Records were updated with the custom classification source. When looking at the call numbers on the backend the call number sort looks like this: itemcallnumber: 14.3 .H673 T942 1956 quote(cn_source): 'boyden' cn_sort: 143_H673T9421956 When using the shelf browser in the OPAC, titles were not sorting correctly. In other words the titles were out of call number order. The example above shows the sort was not properly accounting for the spaces. 2. To remedy the poor sorting, the custom classification source was deleted. The existing description for the Dewey Classification was renamed to Boyden. The "ddc" code, dewey filing, and dewey splitting rules were retained. Records were updated to the renamed classification source. The backend now shows: itemcallnumber: 14.3 .H673 T942 1956 quote(cn_source): 'ddc' cn_sort: 14_300000000000000__H673_T942_1956 The shelf browser in the OPAC sorted the titles correctly by call number and spaces were properly accounted for in the sort. It appears in this scenario that a custom classification source with dewey filing rules was not being properly applied to the call numbers.
I am not sure if this is a bug. The manual documents the way the "sortable" cn_sort is built. Does the behavior match the description?
According to the manual: "For example, a Dewey call number such as ‘636.8/07 SHAW’ will become ‘636_800000000000000_07_SHAW’ in order to be sorted." And: The Dewey filing routine generates a sorted call number by following these rules: - Concatenates classification and item parts. - Converts to uppercase. - Removes any leading or trailing white spaces, and forward slashes (/) - Separates alphabetic prefix from the rest of the call number - Splits into tokens on white spaces and periods. - Leaves first digit group as is. - Converts second digit group to 15-digit long group, padded on right with zeroes. - Converts each whitespace to an underscore. - Removes any remaining non-alphabetical, non-numeric, non-underscore characters. Since the custom classification source used the dewey filing rule and the cn_sort was incorrect, it feels like a bug.
When you say "records were updated to use..." - how was this done? And sorry, I misunderstood at first. I thought you were using the generic filing rule at first, but now I understand it was always ddc, but different classification sources set up to use it.
The example catalog data was updated on the backend by a data specialist. The records can also be updated by batch item modification.
Sounds OK, assuming that the records were "touched" then, not only updated.