[Bug 41932] New: Allow optional zero-padding in items.cn_sort
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Bug ID: 41932 Summary: Allow optional zero-padding in items.cn_sort Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: m.de.rooy@rijksmuseum.nl QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl We have callnumbers like 1 A 1, 10 A 10, 100 A 100 and 1000 A 100. Alphabetically sorting those does not work (100 A 100 < 2 A 2) This proposal includes adding a syspref to define callnumber formats that also specify the desired length when zero-padding cn_sort. This would be active when using C4::ClassSortRoutine::Generic. In the above case we would like to sort them with 0001 A 001, 0010 A 010, 0100 A 100 and 1000 A 100. So the first digit block has length 4, the second block 3. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |m.de.rooy@rijksmuseum.nl |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41936 CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- I'm interested in this. I'm having a similar problem with the generic classification source. I have one library where it would be nice to detect digits and zero pad them to N places to have a more intelligent sort rather than lexicographic sorting. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Are you likely to work on this, Marcel? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #2)
Are you likely to work on this, Marcel?
Yeah see Assignee/status. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Removing 'cruft' from the callnumber should be done after zero padding: | RCE TEST 1.33.45 Mid (1) | RCE_TEST_001033045_MID_1 | We want 1.33.45 not to be interpreted as one digit group (13345) but as three digit groups since the dot serves as delimiter. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 193984 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193984&action=edit Bug 41932: Adjust generic class sort to allow zero-padding Test plan: Run t/ClassSortRoutine_Generic.t Add a few callnumber formats in ClassSortGenericFormats like: ^A:1,3;1,2;;^B:1,2 In words: callnumber starts with A, 1 or more digits (pad to 3), then 1 or more digits (pad to 2). Or callnumber starts with B, one or more digits (pad to 2). Enable generic call number sorting rules in Classification configuration. Now save a few items with callnumbers: 1 A 1, 10 A 2, B2, B11. Check if cn_sort now matches: 001_A_01, 100_A_02, B02, B11. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #6 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #2)
Are you likely to work on this, Marcel?
Here is an impression of where I am at now. This comes from 24.11. I need to polish a bit still: add a preference and description, add a db revision, test on main etc. But it is almost ready. Chose for a preference approach above plugin approach here. Many libraries may want to selectively zero pad with multiple schemes. This is possible by an intelligent use of the pref introduced here working with a filter regex and a list of minimum length versus minimum sort length values. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #6)
(In reply to David Cook from comment #2)
Are you likely to work on this, Marcel?
Here is an impression of where I am at now. This comes from 24.11. I need to polish a bit still: add a preference and description, add a db revision, test on main etc. But it is almost ready.
Chose for a preference approach above plugin approach here. Many libraries may want to selectively zero pad with multiple schemes. This is possible by an intelligent use of the pref introduced here working with a filter regex and a list of minimum length versus minimum sort length values.
Thanks for taking this on. I wanted to do it for one library but couldn't get sponsorship for it. I had thought about doing a totally separate name for it rather than generic though just to have a cleaner separation. Are you thinking of adding the syspref inside C4/ClassSortRoutine/Generic.pm? Or would it be in the caller of get_class_sort_key? Probably cleaner to do the latter. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |dcook@prosentient.com.au |y.org | --- Comment #8 from David Cook <dcook@prosentient.com.au> --- I suppose whether we used a different name than Generic or used a syspref, there will be a little bit of work to do in applying it to existing items. I mean a touch_all_items.pl will do the trick but I suppose we don't want to alter existing behaviour without an option (like a syspref or a different name). Anyway, look forward to seeing more. Happy to QA this one. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #9 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #7)
Are you thinking of adding the syspref inside C4/ClassSortRoutine/Generic.pm? Or would it be in the caller of get_class_sort_key? Probably cleaner to do the latter.
Since the syspref is so tight to the routine that does the work, I think that the current handling within Generic is cleaner. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I have also been wondering if instead of Generic it would be easier to tie this to a new option to avoid any risk of behavior change. Also an idea: To make this more flexible, could it make sense to be able to use a regex based approach to define the "sections" you want to have padded? Almost all of our libraries use their "own" classification scheme. A lot have some form of sequential counter. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #11 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #10)
I have also been wondering if instead of Generic it would be easier to tie this to a new option to avoid any risk of behavior change.
There is no behavior change whatsoever when the preference is empty. There is no pressing reason to duplicate code here (just one new subroutine).
Also an idea: To make this more flexible, could it make sense to be able to use a regex based approach to define the "sections" you want to have padded? Almost all of our libraries use their "own" classification scheme. A lot have some form of sequential counter.
Did you look at the code? This is very flexible already. The pref contains a list of callnumber 'formats'. Each format has an optional regex for filtering (as you mention) and a list of number pairs that control zero-padding digit groups (with a minimum length for each digit group and a padding length). See also the POD in the module and the examples in the test script. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #193984|0 |1 is obsolete| | --- Comment #12 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 194991 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194991&action=edit Bug 41932: Adjust generic class sort to allow zero-padding Test plan: Run t/ClassSortRoutine_Generic.t Add a few callnumber formats in ClassSortGenericFormats like: ^A:1,3;1,2;;^B:1,2 In words: callnumber starts with A, 1 or more digits (pad to 3), then 1 or more digits (pad to 2). Or callnumber starts with B, one or more digits (pad to 2). Enable generic call number sorting rules in Classification configuration. Now save a few items with callnumbers: 1 A 1, 10 A 2, B2, B11. Check if cn_sort now matches: 001_A_01, 100_A_02, B02, B11. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #13 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 194992 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194992&action=edit Bug 41932: Database revision for adding new preference Test plan: Run install or upgrade. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #14 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 194993 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194993&action=edit Bug 41932: Pref description Test plan: Find the pref under Cataloging/Record structure. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #15 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Note: I ran touch_items with the following pref value on a production database: 8,8;; 1,4;1,4;1,4;1,4;; 1,4;1,4;1,4;; 1,4;1,4;; 1,4 We have lots of different types of callnumbers and some weird edge cases etc. But this works fine. The first 8;8 is a kind of no-op that does match dates in a call number and makes that the other formats are skipped in that case. E.g. VEIL-20201010/11 The rest is going from four digit groups back to one digit group in a callnumber. The first four digit groups in any callnumber are zero-padded to 4 positions. 1 A 12 becomes 0001_A_0012. V II 149 1938-1939 (61) becomes V_II_0149_19381939_0061 When adding regexes to the formats, the thing becomes even more flexible. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #15)
Note: I ran touch_items with the following pref value on a production database:
8,8;; 1,4;1,4;1,4;1,4;; 1,4;1,4;1,4;; 1,4;1,4;; 1,4
I think it'll take some time to wrap my head around what this means... Is the whitespace significant? It seems like these formats would be better provided on a per source basis rather than for all Generics? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #17 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #16)
(In reply to Marcel de Rooy from comment #15)
Note: I ran touch_items with the following pref value on a production database:
8,8;; 1,4;1,4;1,4;1,4;; 1,4;1,4;1,4;; 1,4;1,4;; 1,4
I think it'll take some time to wrap my head around what this means...
Is the whitespace significant?
It seems like these formats would be better provided on a per source basis rather than for all Generics?
Sure. I deocumented it on the pref description, in the module, test plan and the test script shows examples. The whitespace is added for readability. And it is ignored in the code. I can obviously move this to a separate module. But all my items are on Generic and this is just a little pref-controlled tweak of Generic imo. See also earlier remarks. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #17)
(In reply to David Cook from comment #16)
(In reply to Marcel de Rooy from comment #15)
Note: I ran touch_items with the following pref value on a production database:
8,8;; 1,4;1,4;1,4;1,4;; 1,4;1,4;1,4;; 1,4;1,4;; 1,4
I think it'll take some time to wrap my head around what this means...
Is the whitespace significant?
It seems like these formats would be better provided on a per source basis rather than for all Generics?
Sure. I deocumented it on the pref description, in the module, test plan and the test script shows examples.
Yeah no I read through that documentation. The syntax is just not very user-friendly. (Not that I have any better recommendations.)
The whitespace is added for readability. And it is ignored in the code.
Cool, I was hoping that was the case.
I can obviously move this to a separate module. But all my items are on Generic and this is just a little pref-controlled tweak of Generic imo. See also earlier remarks.
It just seems a bit risky? Like it would be very easy to get the wrong rule applying to the wrong items? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #18)
I can obviously move this to a separate module. But all my items are on Generic and this is just a little pref-controlled tweak of Generic imo. See also earlier remarks.
It just seems a bit risky? Like it would be very easy to get the wrong rule applying to the wrong items?
What I mean is... even as a separate module I don't think it would be enough? What I've been finding in some libraries is that they make up a variety of call number schemes and expect them all to sort automagically. Of course, they'd have to choose the correct scheme, so maybe having them all as Generic is best to reduce mental load on cataloguers. I don't know. It's a tricky one. In a way, something is better than what we have now. I'm going to need to think more on this one. I should try some of my real world call number examples... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #20 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #19)
It just seems a bit risky? Like it would be very easy to get the wrong rule applying to the wrong items?
What I mean is... even as a separate module I don't think it would be enough?
What I've been finding in some libraries is that they make up a variety of call number schemes and expect them all to sort automagically. Of course, they'd have to choose the correct scheme, so maybe having them all as Generic is best to reduce mental load on cataloguers.
I don't know. It's a tricky one. In a way, something is better than what we have now. I'm going to need to think more on this one.
I should try some of my real world call number examples...
I guess you should try it out. I replaced 400.000 callnumbers and we have a lot of different call number schemes.. At first I was trying to match specific schemes with the (optional) filter regex, but the more general rule I created later (see above) works perfectly. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #20)
I guess you should try it out. I replaced 400.000 callnumbers and we have a lot of different call number schemes.. At first I was trying to match specific schemes with the (optional) filter regex, but the more general rule I created later (see above) works perfectly.
That's cool. Yeah, I'm going to give it a try. Soon I hope as I am pretty keen for this one. It would be a big help to a few of my libraries. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #22 from David Cook <dcook@prosentient.com.au> --- Trying this out now and it's pretty cool. I'm writing additional unit tests to do my testing, and I realise that it would be great to have a UI where people could test their classification configuration/sources. I'm going to raise a report for that: bug 42123 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42123 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194991|0 |1 is obsolete| | --- Comment #23 from David Cook <dcook@prosentient.com.au> --- Created attachment 195609 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195609&action=edit Bug 41932: Adjust generic class sort to allow zero-padding Test plan: Run t/ClassSortRoutine_Generic.t Add a few callnumber formats in ClassSortGenericFormats like: ^A:1,3;1,2;;^B:1,2 In words: callnumber starts with A, 1 or more digits (pad to 3), then 1 or more digits (pad to 2). Or callnumber starts with B, one or more digits (pad to 2). Enable generic call number sorting rules in Classification configuration. Now save a few items with callnumbers: 1 A 1, 10 A 2, B2, B11. Check if cn_sort now matches: 001_A_01, 100_A_02, B02, B11. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194992|0 |1 is obsolete| | --- Comment #24 from David Cook <dcook@prosentient.com.au> --- Created attachment 195610 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195610&action=edit Bug 41932: Database revision for adding new preference Test plan: Run install or upgrade. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194993|0 |1 is obsolete| | --- Comment #25 from David Cook <dcook@prosentient.com.au> --- Created attachment 195611 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195611&action=edit Bug 41932: Pref description Test plan: Find the pref under Cataloging/Record structure. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #26 from David Cook <dcook@prosentient.com.au> --- Created attachment 195612 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195612&action=edit Bug 41932: (follow-up) Improve syspref description and add more unit tests This change improves the formatting of the syspref description, and tries to clarify how the zero-padding formats work along with some examples. The unit tests include the examples from the syspref description as well as some examples of real world generic call numbers. Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|dcook@prosentient.com.au |testopia@bugs.koha-communit | |y.org --- Comment #27 from David Cook <dcook@prosentient.com.au> --- This is really cool. Thanks, Marcel, for putting this together. I took the liberty of adding some more unit tests and tweaking the syspref description to hopefully make it easier to understand. Once I understood the zero-padding formats, it became really clear how it all works. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #28 from David Cook <dcook@prosentient.com.au> --- If this were pushed tomorrow, people wouldn't see any difference with their generic call numbers, because there are no formats out of the box, so it's a very low risk change. It would be such a game changer for a number of my libraries. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #29 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #27)
This is really cool. Thanks, Marcel, for putting this together. I took the liberty of adding some more unit tests and tweaking the syspref description to hopefully make it easier to understand.
Once I understood the zero-padding formats, it became really clear how it all works.
Ah, great. Thx for testing and adding the follow-up. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #30 from David Cook <dcook@prosentient.com.au> --- Would love to get this into Koha. Maybe after the next big release it'll be easier... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #31 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #30)
Would love to get this into Koha. Maybe after the next big release it'll be easier...
Everything gets stuck in the SO queue nowadays. I dont know why this should wait for the next release. No behavior change when you dont change the pref. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #32 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #31)
(In reply to David Cook from comment #30)
Would love to get this into Koha. Maybe after the next big release it'll be easier...
Everything gets stuck in the SO queue nowadays. I dont know why this should wait for the next release. No behavior change when you dont change the pref.
Agreed. It's such a low risk change. That said, I suppose the test plans aren't super user-friendly. David Nind mentioned recently if something sits for a while it might be because he (and others) aren't able to understand the test plan (if there is one). Because if we could get a SO then we could handle the QA part. I'm done for the week now (5:19pm on Friday in Australia), but hopefully it can still make it into 26.05! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195609|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195610|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195611|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195612|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #33 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 198700 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198700&action=edit Bug 41932: Adjust generic class sort to allow zero-padding Test plan: Run t/ClassSortRoutine_Generic.t Add a few callnumber formats in ClassSortGenericFormats like: ^A:1,3;1,2;;^B:1,2 In words: callnumber starts with A, 1 or more digits (pad to 3), then 1 or more digits (pad to 2). Or callnumber starts with B, one or more digits (pad to 2). Enable generic call number sorting rules in Classification configuration. Now save a few items with callnumbers: 1 A 1, 10 A 2, B2, B11. Check if cn_sort now matches: 001_A_01, 100_A_02, B02, B11. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #34 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 198701 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198701&action=edit Bug 41932: Database revision for adding new preference Test plan: Run install or upgrade. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> [EDIT] Removed options, explanation and type -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #35 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 198702 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198702&action=edit Bug 41932: Pref description Test plan: Find the pref under Cataloging/Record structure. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #36 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 198703 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198703&action=edit Bug 41932: (follow-up) Improve syspref description and add more unit tests This change improves the formatting of the syspref description, and tries to clarify how the zero-padding formats work along with some examples. The unit tests include the examples from the syspref description as well as some examples of real world generic call numbers. Signed-off-by: David Cook <dcook@prosentient.com.au> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #37 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Rebased for change on systempreference fields options, explanation and type. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 --- Comment #38 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #37)
Rebased for change on systempreference fields options, explanation and type.
Cheers! I wonder if we should try to recruit someone else to sign off so that I can mark it Passed QA? -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org