Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in Germany and possibly other countries. A lot of our libraries use their own custom classification schemes so the call number splitting is something that should be individually configurable. One option would be using a regex expression, that can be set in the layout additional to the standard splitting offered by the checkbox. (see bug 2500 for some discussion about the splitting algorithms implemented atm)
For background information, see: http://blog.l2c2.co.in/index.php/2016/08/26/koha-spine-label-is-not-printing-the-in-your-call-numbers-here-is-why/
Created attachment 76691 [details] [review] Bug 15836: DB changes
Created attachment 76692 [details] [review] Bug 15836: DBIC Schema change
Created attachment 76693 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template.
Created attachment 76694 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily.
Created attachment 76695 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed
Created attachment 76696 [details] Screenshot of the feature
Created attachment 77061 [details] [review] Bug 15836: Add tests
Just found this test file in my local repo. It sounds like it belongs to this one...
Created attachment 77079 [details] [review] Bug 15836: Add missing svc script
Hi Jonathan, we have tested the basic functionality and are happy about the results of the test button and the results in the generated PDF. We also found some issues: 1) There is an error if you try to edit an existing non-Regex splitting rule: Template process failed: undef error - malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/perl5/JSON.pm line 171. at /home/vagrant/kohaclone/C4/Templates.pm line 122 2) If you try to print the PDF for labels with ddc/loc splitting rule, there is also an error: malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/perl5/JSON.pm line 171 We are not sure on how to solve the security issue. I think switching to TT would not be good in this case, as it would be harder do write and people would try to do more formatting that is probably not supported by the labels right now. Maybe an approach splitting the regex into muliple fields similar to the MARC modification templates GUI could work. Instead of hardcoding /ig, maybe a pull down? Open to your and others' suggestions.
> * Should not we use a LONGTEXT for class_split_rules.split_regex instead > of VARCHAR(255)? varchar(255) seems enough.
Created attachment 77306 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules
(In reply to Katrin Fischer from comment #11) > Hi Jonathan, Hi Katrin, thanks for testing! > we have tested the basic functionality and are happy about the results of > the test button and the results in the generated PDF. Good to hear :) > We also found some issues: Must be fixed with the last patch. > We are not sure on how to solve the security issue. I think switching to TT > would not be good in this case, as it would be harder do write and people > would try to do more formatting that is probably not supported by the labels > right now. > > Maybe an approach splitting the regex into muliple fields similar to the > MARC modification templates GUI could work. Instead of hardcoding /ig, maybe > a pull down? Open to your and others' suggestions. My guess it that MMT does not work with $1 either, I think we will also need /e for that.
*** Bug 12201 has been marked as a duplicate of this bug. ***
The last patch fixes the 2 errors. Looking at the functionality, we are ready to sign-off, but worried about the security issue. If I understood correctly the use of $1 is related to the eval happening and it won't work without. For the current use case, the line s/^(J|K)\n/$1 could be replaced by 2 lines for K and J, not using $1. So we might be able to cut that feature, if it would help.
Created attachment 78791 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template.
Created attachment 78793 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily.
Created attachment 78795 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed
Created attachment 78796 [details] [review] Bug 15836: Add tests
Created attachment 78798 [details] [review] Bug 15836: Add missing svc script
Created attachment 78799 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules
Created attachment 79029 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx
Patch tested with a sandbox, by Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80339 [details] [review] Bug 15836: DB changes Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80340 [details] [review] Bug 15836: DBIC Schema change Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80341 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80342 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80343 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80344 [details] [review] Bug 15836: Add tests Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80345 [details] [review] Bug 15836: Add missing svc script Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80346 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80347 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Hi Jonathan, I have few questions: 1. Why do you decide to make new modules under C4 namespace? 2. The patches are not applicable on top of bug 14931, should it depend on it?
(In reply to Josef Moravec from comment #34) > Hi Jonathan, > > I have few questions: > > 1. Why do you decide to make new modules under C4 namespace? I have mimicked what was done in C4::ClassSortRules. It sounded better to keep them tied at the same place (ClassSource.pm, ClassSortRoutine.pm and ClassSplitRoutine.pm) > 2. The patches are not applicable on top of bug 14931, should it depend on > it? It's bug 14391, and it does not apply anymore. I will rebase on top when ready.
Created attachment 80548 [details] [review] Bug 15836: DB changes Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80549 [details] [review] Bug 15836: DBIC Schema change Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80550 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80551 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80552 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80553 [details] [review] Bug 15836: Add tests Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80554 [details] [review] Bug 15836: Add missing svc script Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80555 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 80556 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Created attachment 81033 [details] [review] Bug 15836: DB changes Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81034 [details] [review] Bug 15836: DBIC Schema change Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81035 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81036 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily. Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81037 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81038 [details] [review] Bug 15836: Add tests Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81039 [details] [review] Bug 15836: Add missing svc script Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81040 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81041 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81627 [details] [review] Bug 15836: DB changes Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81628 [details] [review] Bug 15836: DBIC Schema change Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81629 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template. Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81630 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily. Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81631 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81632 [details] [review] Bug 15836: Add tests Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81633 [details] [review] Bug 15836: Add missing svc script Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81634 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 81635 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
I have added the "Sponsored-by" line" to the patches.
Thank you, Joubu!
Created attachment 82110 [details] [review] Bug 15836: Fix update DB entry
Created attachment 82112 [details] [review] Bug 15836: Fix DB structure That was a leftover from the first approach, this table must not be modified!
Created attachment 82113 [details] [review] Bug 15836: DBIC Schema change
Created attachment 82118 [details] [review] Bug 15836: Fix DB structure That was a leftover from the first approach, this table must not be modified! Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 82119 [details] [review] Bug 15836: DBIC Schema change Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 82120 [details] [review] Bug 15836: (follow-up) Fix filters Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Retested on a fresh database created running the web installer with all sample data.
I tried my best here but am still having issues Minor conflicts on filters After this patch I cannot delete classification sources, I end up on a blank page There is debug code in /home/vagrant/kohaclone/svc/split_callnumbers (Data printer line 14) I cannot save regex rules - I can add and test, but they are lost when I hit save. Possibly I messed up something when fixing filters, can you please double check?
Created attachment 82289 [details] [review] Bug 15836: DB changes Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82290 [details] [review] Bug 15836: UI changes The script admin/classsources.pl has been adjusted to follow usual patterns used in other Koha scripts. $op can be add_source, add_source_validate, etc. Deletion steps have been removed (there is a JS confirmation box) to simplify both script and template. Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82291 [details] [review] Bug 15836: Add the ability to defined custom methods to split call number in labels Currently the call number splitting seems to be mostly implemented for DDC and LC classifications. Those are both not very common in some countries. A lot of libraries use their own custom classification schemes so the call number plitting is something that should be individually configurable. This enhancement adds the ability to define custom splitting rules based on regular expressions. How does it work so far? From C4/Labels/Label.pm there are 3 differents splitting methods defined, depending on items.cn_source. if cn_source is "lcc' or 'nlm' we split using Library::CallNumber::LC if cn_source is 'ddc' we split using a in-house method Finally there is a fallback method to split on space And nothing else is done for other cn_source The idea of this patch is to mimick what was done for the "filing rules" and add the ability to define "splitting rules" that will be used by the "Classification sources". A classification source will then have: * a filing rule used to sort items by callnumbers * a splitting rule used to print labels To acchieve this goal this enhancement will do the following modifications at DB level: * New table class_split_rules * New column class_sources.class_split_rule Test plan: * Execute the update database entry to create the new table and column. I. UI Changes a) Create/modify/delete a filing rule b) Create/modify/delete a splitting rule c) Create/modify/delete a classification source => A filing rule or splitting rule cannot be removed if used by a classification source II. Splitting rule using regular expressions a) Create a splitting rule using the "Splitting routine" "RegEx" b) Define several regular expressions, they will be applied one after the other in the same order you define them. Something like: s/\s/\n/g # Break on spaces s/(\s?=)/\n=/g # Break on = (unless it's done already) s/^(J|K)\n/$1 / # Remove the first break if callnumber starts with J or K c) You can test the regular expressions using filling the textarea with a list of callnumbers. Then click "Test" and confirm the callnumbers are split how you expected. d) Finally create a new classification source that will use this new splitting rule. III. Print the label! a) Create a layout. It should have the "Split call numbers" checkbox ticked, and display itemcallnumber b) Use this layout to export labels, use items with different classification source ('lcc', 'ddc', but also the new one you have create) => The callnumbers should have been split according to the regex you defined earlier! Notes: * The update database entry fill the class_sources.class_split_rule with the value of class_sources.class_sort_rule If default rules exist it will not work, we should add a note in the release notes (would be enough?) * C4::ClassSplitRoutine::* should be moved to Koha::ClassSplitRule, but it sounded better to keep the same pattern as ClassSortRoutines * Should not we use a LONGTEXT for class_split_rules.split_regex instead of VARCHAR(255)? * class_sources.sql should be filled for other languages before pushed to master! IMPORTANT NOTES: The regular expressions are stored as it, and eval is used to evaluate it (perlcritic raises a warning about it (Expression form of "eval"). It can lead to serious security issues (execution of arbitrary code on the server), especially if the modifier 'e' is used. We could then remedy the situation with one of these following points: - Assume that this DB data is safe (We can add a new permission?) - Assume that the data is not safe and deal with possible attack Cons: how be sure we are exhaustive? Making sure it matches ^s///[^e/]*$ would be enough? - Use Template Toolkit syntax instead (Really safer?) [% callnumber.replace('\s', '\n').replace ... %] - Cut the regex parts: find, replace, modifiers like we already do for Marc modification template. Cons: we are going to have escape problems, the "find" and "replace" parts should not be handle the same way (think "\n", "\\n", "\1", "\s", etc.) I did not manage to implement this one easily. Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82292 [details] [review] Bug 15836: Mark C4::ClassSource subs DEPRECATED These subs are no longer used from scripts and should be removed. It should be done on a separate bug report given that additional work is needed Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82293 [details] [review] Bug 15836: Add tests Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82294 [details] [review] Bug 15836: Add missing svc script Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82295 [details] [review] Bug 15836: Handle non-existent regexs For other types of split rules Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82296 [details] [review] Bug 15836: Fix display input in any situations Fix when switching an existing rule to RegEx Sponsored-by: Goethe-Institut Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 82297 [details] [review] Bug 15836: Fix DB structure That was a leftover from the first approach, this table must not be modified! Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 82298 [details] [review] Bug 15836: DBIC Schema change Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 82299 [details] [review] Bug 15836: (follow-up) Fix filters Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 82300 [details] [review] Bug 15836: Fix deletion of class sources
Created attachment 82301 [details] [review] Bug 15836: Remove debug statement
Created attachment 82302 [details] [review] Bug 15836: (follow-up) Fix display input in any situations Koha::ClassSplitRule->regexs returns an array
Awesome work all! Pushed to master for 18.11
Created attachment 82317 [details] [review] Bug 15836: Fix failing tests
Created attachment 82318 [details] [review] Bug 15836: Remove deprecated subroutines It will take too much time to fix the failures here, given the simplicity of the subroutines I would be in favor of deleting them and continue the move on a separate bug report to use Koha::Object-objects
Created attachment 82319 [details] [review] Bug 15836: Remove deprecated subroutines It will take too much time to fix the failures here, given the simplicity of the subroutines I would be in favor of deleting them and continue the move on a separate bug report to use Koha::Object-objects
Created attachment 82321 [details] [review] Bug 15836: Remove deprecated subroutines It will take too much time to fix the failures here, given the simplicity of the subroutines I would be in favor of deleting them and continue the move on a separate bug report to use Koha::Object-objects Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> I've checked that everything removed is no longer in use.
(In reply to Katrin Fischer from comment #91) > Created attachment 82321 [details] [review] [review] > Bug 15836: Remove deprecated subroutines > > It will take too much time to fix the failures here, given the > simplicity of the subroutines I would be in favor of deleting them and > continue the move on a separate bug report to use Koha::Object-objects > > Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> > I've checked that everything removed is no longer in use. Last two patches pushed to master
Enhancement, will not be backported to 18.05.x series.
FYI, the DB schema changes in https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=82289 are incomplete/incorrect. 1) Table "class_sources" gets its "class_split_rule" pre-filled with the existing "class_sort_rule" counterparts, yet the "class_split_rules" table is only filled with fixed presets. Thus adding the "class_source_ibfk_2" constraint will fail as soon as there are more sort rules than split rules, that is, as soon as there are any custom sort rules. 2) The "class_split_rules" preset values are apparently copied from the "class_sort_rules" rules, leaving the "sorting rules" fragment in their descriptions. Those are presumably meant to be called "splitting rules". Best, Oliver
(In reply to Oliver Behnke from comment #94) > FYI, the DB schema changes in > https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=82289 are > incomplete/incorrect. > > 1) Table "class_sources" gets its "class_split_rule" pre-filled with the > existing "class_sort_rule" counterparts, yet the "class_split_rules" table > is only filled with fixed presets. Thus adding the "class_source_ibfk_2" > constraint will fail as soon as there are more sort rules than split rules, > that is, as soon as there are any custom sort rules. > > 2) The "class_split_rules" preset values are apparently copied from the > "class_sort_rules" rules, leaving the "sorting rules" fragment in their > descriptions. Those are presumably meant to be called "splitting rules". > > Best, > Oliver Hi Oliver, can you please file this as a separate bug report and link to this bug using the "Depends"? Once a bug is pushed, closed and released like this, we always need a new one for tracking the change.
Done.
Adding see also for removing unused code