This is certainly a major issue that leads to many side-effects.
Under plack, the structure of the default values are not handled
correctly.
Package variables are used to store stuff like the "layout type". They
are complex structures (arrays of hashes) and returned without being
copied.
When the caller (the controller script) retrieve them then modify the
returned structures, it actually modifies the package's variables.
One of the issue is:
Create a new layout
The script retrieve a structure with all "selected" flags are set to 0
It select the first one as default (BAR as selected => 1)
The user creates the new layout and will selected BIBBAR (for instance)
If you then edit this new layout, the script will retrieve the
"label_types" and set "selected" for BIBBAR. However BAR is still
selected!
The UI receives 2 selected and display the first selected one that has
the selected option.
Test plan:
1. Create a layout type for Barcode/Biblio
2. Choose fields to print and size of font
3. Save
4. Edit existing Layout
=> Withtout this patch "Barcode" is the preselected option
=> With this patch applied, the correct "Barcode/Biblio" option is
selected
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a .perlcriticrc (copied from qa-test-tools) and fixes
almost all perlcrictic violations according to this .perlcriticrc
The remaining violations are silenced out by appending a '## no critic'
to the offending lines. They can still be seen by using the --force
option of perlcritic
This patch also modify t/00-testcritic.t to check all Perl files using
the new .perlcriticrc.
I'm not sure if this test script is still useful as it is now equivalent
to `perlcritic --quiet .` and it looks like it is much slower
(approximatively 5 times slower on my machine)
Test plan:
1. Run `perlcritic --quiet .` from the root directory. It should output
nothing
2. Run `perlcritic --quiet --force .`. It should output 7 errors (6
StringyEval, 1 BarewordFileHandles)
3. Run `TEST_QA=1 prove t/00-testcritic.t`
4. Read the patch. Check that all changes make sense and do not
introduce undesired behaviour
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
'koha_kohadev.creator_batches.description' isn't in GROUP BY
Fix t/db_dependent/Creators/Lib.t if strict sql modes is on
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a 'description' column to the creator_batches table. The
description for a batch can be added and updated using ajax.
To test:
1) Apply patch and update database (you will have to restart memcached)
2) Go to Tools -> Patron card creator -> Manage batches
3) There should now be a Description column next to Batch ID. This
will be empty (as none of the batches have descriptions yet)
4) Click Edit for any batch
5) Notice new Batch description text field. Enter a description for
the batch in here and click Save description. Some text should show
saying the description was saved.
6) If you go back to the manage batches page, the description should
now show under the Description column.
7) Go to Tools -> Label Creator -> Manage labels
8) Repeat steps 3 to 6
Sponsored-by: Catalyst IT
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Added a (initially trivial) test in Creators/Lib.t too.
Sometimes you start something, but you end somewhere else ;)
The test seems a bit slower now (regex, lookahead, etc). But this should
not hurt label creators in daily use.
Advantages: code is even more solid, consolidated in one place and can be
tested on its own.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
TEST PLAN
---------
1) apply first patch
2) kshell kohadev
3) prove -r -v t/db_dependent/Creators/
-- failures
4) apply this patch
5) repeat 2,3
-- no failures
6) run koha qa test tools
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
'rows' is a reserved word since MariaDB 10.2.4 and MySQL
https://mariadb.com/kb/en/library/mariadb-1024-release-notes/https://dev.mysql.com/doc/refman/8.0/en/keywords.html
Test plan:
Do not apply this patch and make sure you recreate the reported issue
Apply this patch and confirm that it is now fixed.
QA will take care for the changes in installer and test files
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To reproduce:
Go to Home > Tools > Patron card creator
Click on 'Manage profiles'
Result:
Can't use string ("1") as an ARRAY ref while "strict refs" in use at /usr/share/kohaclone/C4/Creators/Lib.pm line 564.
Reason:
Select statment to get field 'template code' from table 'club_template_enrollment_fields' (!) instead of 'table creator_templates'.
To test:
Apply patch
Try to reproduce issue.
Amended because of typo (_ instead of -)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
SQL expects lists to be comma separated. A trailing comma must also
be avoided.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To recreate:
/cgi-bin/koha/patroncards/edit-template.pl?op=edit&element_id=23%20and%201%3d2+union+all+select+1,user(),@@version+--%20
Look at the Profile dropdown list.
To fix this problem and to make sure it does not appears anywhere else
in the label and patroncards modules, I have refactored the way the
queries are built in C4::Creators::Lib
Now all of the subroutine takes a hashref in parameters with a 'fields'
and 'filters' parameters.
From these 2 parameters the new internal subroutine _build_query will
build the query and use placeholders.
Test plan:
1/ Make sure you do not recreate the vulnerability with this patch
applied.
2/ With decent data in the labels and patroncards modules, compare all
the different view (undef the New and Manage button groups) with and
without this patch applied.
=> You should not see any differences.
This vulnerability has been reported by MDSec.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Create a label batch
2 - Add some items
3 - Note you do not see callnumber
4 - Apply patch
5 - Verify callnumber displays correctly
6 - Verify batch functions (adding, exporting, removing, etc) work as
before
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This deals with my concerns raised in comment #2.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Testing C4::Creators::Lib at 100%
Deleting get_column_names subroutine (never used)
TEST PLAN
---------
1. Apply patch
2. prove -v t/db_dependent/Creators/Lib.t
-- All 644 tests should run successfully without
any error or warning
TEST PLAN OPTIONAL
------------------
Check with bug 13899 to see the coverage of this module.
Coverage BEFORE this patch :
Statement : 11,6%
Branch : 0,0%
Condition : N/A
Subroutine : 36,0%
Coverage AFTER this patch :
Statement : 100,0%
Branch : 100,0%
Condition : N/A
Subroutine : 100,0%
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
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>
This patch fixes two problems:
a) Bad PDF when using Helvetica font.
Current label code assigns 'italic' or 'oblique' variants
to title. Helvetica-Oblique was not defined, but is present
b) Bad alignment using center/right justification
Problem was bad font parameter passed to StrWidth
routine
To test:
1. Try making a batch using Helvetica, downloaded PDF do not open.
2. Try a batch of mixed scripts with layout alignment center or
right, only latin scripts align almost correctly.
3. Apply the patch and update your koha-conf.xml to add Oblique variant
4. Try again 1, now PDF opens
5. Try 2, now alignment is correct
New problem (for another bug): DejaVuSans has a good
support for arabic, but not Oblique variant. As selection
of italic/oblique is hardcoded, now Arabic titles are
not displayed. I'll try to add a checkbox to select
or not this feature.
Added a FIXME for the hardcoded forced oblique -chris_n
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch updates the example template syntax in the POD for
C4::Creators::Lib::html_table() to use Template Toolkit syntax.
To test, view the POD for C4::Creators::Lib::html_table() and confirm
that it looks correct.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Checked the POD with "perldoc C4/Creators/Lib.pm" before and after applying
the patch. The example now uses TT syntax, and looks sensible.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Current implementation doesn't scale barcodes because low-price
CCD barcode readers are very sensitive about size
Test scenario:
1. in Tools > Labels create or edit Layout and select EAN13 as barcode
type
2. export one of existing batches using EAN13 layout and verify that
generated pdf file contains barcodes
3. print pdf file and test it with barcode reader
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
current code is using DISTINCT and another SQL query which can be replaced with GROUP BY
for massive speedup. In our case, generating Manage Batches screen DBI time decreased
from 24.762 s to 0.147 s
Aside from correct usage of relational database, this change also cleans up code nicely.
This change removed semi-columns from SQL query which broke Manage Patron batches.
Test scenario:
1. open Manage Batches screen and take note of time needed to generate it
2. apply this patch
3. reload page and check page genration time
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
working through the master branch to eliminate all
podchecker warnings/errors
Actual improvement to the quality of the POD will
come later (hopefully with assistance of others)
Signed-off-by: Andrew Elwell <Andrew.Elwell@gmail.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This reverts commit 1f56a04cad.
[RM note: I confirm Chris Nighswonger's testing that shows that
the patch causes regressions, including breaking creating new
label layouts.]
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
A lot of routines were defaulting to return -1 in error conditions
but calling code was expecting a ref or object
use return with explicit undef (or emptyness in array context)
for these cases. Extended this to cases where return was not tested
( -1 might in some cases be legit data).
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
(cherry picked from commit 5cf2b78b6f)
[RM note: ... thereby undoing the revert]
A lot of routines were defaulting to return -1 in error conditions
but calling code was expecting a ref or object
use return with explicit undef (or emptyness in array context)
for these cases. Extended this to cases where return was not tested
( -1 might in some cases be legit data).
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
