> However, Jason reports finding what appears to be a logic flaw in the
> code. Has written a patch that corrects it. A coincidental byproduct
> is that it ends up sorting the user's call numbers as desired, despite
> using wrong scheme. Not sure how I'd classify that. Also not qualified
> to evaluate efficiently, so bowing out of that discussion. (Jason,
> still fine to use it on our test system if needing data to try it on.)
If the consensus is that the Dewey classification should be very
strict in what it allows (and there have only been a handful of folks
weighing in on this ticket, so who knows), then the real bug is that
we're not strict here. Should non-Dewey call numbers fall to the end
of the list if using the Dewey classification? Maybe have a fallback
to Generic as a sub-sort?
> However, Jason reports finding what appears to be a logic flaw in the
> code. Has written a patch that corrects it. A coincidental byproduct
> is that it ends up sorting the user's call numbers as desired, despite
> using wrong scheme. Not sure how I'd classify that. Also not qualified
> to evaluate efficiently, so bowing out of that discussion. (Jason,
> still fine to use it on our test system if needing data to try it on.)
Thanks for the offer.
For what it's worth, I'm getting this fixed in Koha; I just need to bugs.koha- community. org/bugzilla3/ show_bug. cgi?id= 9770
write a test for it:
http://
If the consensus is that the Dewey classification should be very
strict in what it allows (and there have only been a handful of folks
weighing in on this ticket, so who knows), then the real bug is that
we're not strict here. Should non-Dewey call numbers fall to the end
of the list if using the Dewey classification? Maybe have a fallback
to Generic as a sub-sort?