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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
So far the administration module only allowed for 2 permissions:
- circulation conditions (manage_circ_rules)
- everything else (parameters_remaining_permissions)
With this patch almost every section of the administration page
will have its own granular permission.
To test:
- Create different staff users:
1) One with parameters_remaining_permissions
2) One with parameters
3) One with catalogue and no parameters
4) One superlibrarian
- Apply the patch
- Run the database update
- Check the staff users:
1) All subpermissions, but manage_circ_rules
should be checked
2) Nothing should have changed
3) manage_item_serach_fields shoudl be checked
(page had catalogue permission before)
4) Nothing should have changed
- Try different settings of the permissions and
verify that
- Administration page behaves correctly
- Administration menu behaves correctly
! You shoudl only see what you have permission for
https://bugs.koha-community.org/show_bug.cgi?id=14391
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
Check use warnings; use strict doesn't exist and use Modern::Perl is written instead in the following files:
admin/admin-home.pl
admin/aqcontract.pl
admin/aqplan.pl
admin/auth_tag_structure.pl
admin/branch_transfer_limits.pl
admin/check_budget_parent.pl
admin/check_parent_total.pl
admin/checkmarc.pl
admin/classsources.pl
admin/clone-rules.pl
admin/didyoumean.pl
admin/edi_accounts.pl
admin/edi_ean_accounts.pl
admin/import_export_framework.pl
admin/item_circulation_alerts.pl
admin/marctagstructure.pl
admin/matching-rules.pl
admin/printers.pl
admin/smart-rules.pl
admin/systempreferences.pl
admin/transport-cost-matrix.pl
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to Admin -> Classification sources
2) Attempt to reproduce bug before applying patch. Notice the message
saying the add was successful, but was not added to the table
3) Apply patch and refresh page (restart plack if necessary)
4) Add new classification source with same code as existing one. Notice
you are now told that the add failed.
5) Confirm adding new classification source with unique code works
6) Add new classification filing rule with same code as existing one.
Notice you are told that add failed.
7) Confirm adding new classification filing rule with unique code works
Sponsored-by: Catalyst IT
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
This is not the way to go, we should use an eval instead.
But since we do not have RaiseError set, it will not work.
This module will need to be moved to Koha::Objects to be implemented
correctly.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Because of a wrong variable scope, the classification sources are not
deletable.
Test plan:
Create a classification sources (admin/classsources.pl)
Try to delete it
Without this patch, the classification source won't be deleted
With this patch, it will work!
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Relatively minor cleaning.
Remove unused javascript. Add row highlighting to both tables. Remove conditionals where the
behavior is the same for both possibilities.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Database schema definitions and system preferences support
for defining classification sources and filing rules.
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
