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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch does two things to improve the call number splitting algorithms:
1. It makes changes to ensure that cutter numbers are split correctly in ddcns
2. It moves custom/fiction/biography call number splitting to a separate algorithm.
Before they were incorrectly placed in ddcns.
This patch also modifies the call number splitting tests to accept call numbers from the
command line to allow quick testing of any give call number against a particular algorithm.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Presently 252.051 T147 v.1-2 is split as
252.051
T147
v.1
-2
This patch corrects the algorithm so that it splits as
252.051
T147
v.1-2
It also updates Labels_split_ddcn.t to include this particular case.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Allow a call number of the form MP3-CD F PARKER to be split as
MP3-CD
F
PARKER
instead of
MP
3
-CD
F
PARKER
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
If a call number prefix contains a hyphen, try not to
split on the hyphen. For example, rather than
splitting the call number 'CD-ROM 787.87 EAS'
like this:
CD
-ROM
787.87
EAS
it should be
CD-ROM
787.87
EAS
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Similar to previous patch for LCCN splitting, this patch incorporates
changes to split_ddcn and supplies a test file for verifying proper
operation. Note that the only previously documented example for intended
operation is included as one of the tests.
This regexps are created to be rather forgiving. For example, the function
will not choke if two spaces were included where the "spec" (such as it is)
expects one. Obviously this is because for CN splitting purposes, it doesn't
matter, we're not going to ever split in the middle of whitespace.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
