Bug 15836 - Labels: Offer configuration option for splitting call numbers
Summary: Labels: Offer configuration option for splitting call numbers
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
: 12201 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-02-17 09:53 UTC by Katrin Fischer
Modified: 2018-09-16 23:25 UTC (History)
7 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 15836: DB changes (6.64 KB, patch)
2018-07-04 16:11 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: DBIC Schema change (4.77 KB, patch)
2018-07-04 16:11 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: UI changes (40.35 KB, patch)
2018-07-04 16:11 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Add the ability to defined custom methods to split call number in labels (37.97 KB, patch)
2018-07-04 16:11 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Mark C4::ClassSource subs DEPRECATED (2.38 KB, patch)
2018-07-04 16:11 UTC, Jonathan Druart
Details | Diff | Splinter Review
Screenshot of the feature (55.71 KB, image/png)
2018-07-04 16:12 UTC, Jonathan Druart
Details
Bug 15836: Add tests (2.08 KB, patch)
2018-07-17 18:55 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Add missing svc script (3.91 KB, patch)
2018-07-18 15:48 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Handle non-existent regexs (1.92 KB, patch)
2018-07-27 13:13 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: UI changes (41.26 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Add the ability to defined custom methods to split call number in labels (37.97 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Mark C4::ClassSource subs DEPRECATED (2.38 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Add tests (2.08 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Add missing svc script (3.91 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Handle non-existent regexs (1.92 KB, patch)
2018-09-14 22:25 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 15836: Fix display input in any situations (1.17 KB, patch)
2018-09-16 23:25 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2016-02-17 09:53:46 UTC
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)
Comment 2 Jonathan Druart 2018-07-04 16:11:22 UTC
Created attachment 76691 [details] [review]
Bug 15836: DB changes
Comment 3 Jonathan Druart 2018-07-04 16:11:27 UTC
Created attachment 76692 [details] [review]
Bug 15836: DBIC Schema change
Comment 4 Jonathan Druart 2018-07-04 16:11:31 UTC
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.
Comment 5 Jonathan Druart 2018-07-04 16:11:36 UTC
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.
Comment 6 Jonathan Druart 2018-07-04 16:11:41 UTC
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
Comment 7 Jonathan Druart 2018-07-04 16:12:58 UTC
Created attachment 76696 [details]
Screenshot of the feature
Comment 8 Jonathan Druart 2018-07-17 18:55:58 UTC
Created attachment 77061 [details] [review]
Bug 15836: Add tests
Comment 9 Jonathan Druart 2018-07-17 18:56:11 UTC
Just found this test file in my local repo. It sounds like it belongs to this one...
Comment 10 Jonathan Druart 2018-07-18 15:48:42 UTC
Created attachment 77079 [details] [review]
Bug 15836: Add missing svc script
Comment 11 Katrin Fischer 2018-07-27 09:21:37 UTC
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.
Comment 12 Katrin Fischer 2018-07-27 09:23:03 UTC
> * Should not we use a LONGTEXT for class_split_rules.split_regex instead
> of VARCHAR(255)?

varchar(255) seems enough.
Comment 13 Jonathan Druart 2018-07-27 13:13:40 UTC
Created attachment 77306 [details] [review]
Bug 15836: Handle non-existent regexs

For other types of split rules
Comment 14 Jonathan Druart 2018-07-27 13:15:54 UTC
(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.
Comment 15 Katrin Fischer 2018-07-27 13:35:03 UTC
*** Bug 12201 has been marked as a duplicate of this bug. ***
Comment 16 Katrin Fischer 2018-07-27 14:50:58 UTC
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.
Comment 17 Jonathan Druart 2018-09-14 22:25:35 UTC
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.
Comment 18 Jonathan Druart 2018-09-14 22:25:39 UTC
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.
Comment 19 Jonathan Druart 2018-09-14 22:25:45 UTC
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
Comment 20 Jonathan Druart 2018-09-14 22:25:49 UTC
Created attachment 78796 [details] [review]
Bug 15836: Add tests
Comment 21 Jonathan Druart 2018-09-14 22:25:54 UTC
Created attachment 78798 [details] [review]
Bug 15836: Add missing svc script
Comment 22 Jonathan Druart 2018-09-14 22:25:58 UTC
Created attachment 78799 [details] [review]
Bug 15836: Handle non-existent regexs

For other types of split rules
Comment 23 Jonathan Druart 2018-09-16 23:25:57 UTC
Created attachment 79029 [details] [review]
Bug 15836: Fix display input in any situations

Fix when switching an existing rule to RegEx