When incremental EAN-13 barcodes are selected for autoBarcode and new item
records are created an unexpected sequence of barcode numbers is produced
instead of a sequence where the barcode is incremented by 1 between each item.
This patch fixes that by adding quote marks in the inline JS, thus treating the
barcode as a string rather than an integer :+)
Test plan:
1. have records imported from somewhere but with no items
2. autoBarcode set to incremental EAN-13 barcodes
3. create a number of new items
4. observe that the item barcodes don't follow the expected sequence
5. apply patch
6. delete item records
7. repeat step 3
8. observe that the item barcodes follow the expected sequence
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The EAN-13 barcode query used max(abs(barcode)) which allowed non-EAN-13
barcodes (e.g. 14-digit KTD sample barcodes) to dominate the result.
The saved 13-digit EAN-13 barcodes were always smaller, so $nextnum
never advanced and the same barcode was generated on every page load.
Fix by extracting EAN-13 logic into C4::Barcodes::ValueBuilder::EAN13
(consistent with other barcode type packages) and scoping the query to
WHERE length(barcode) = 13 so only valid-length barcodes contribute to
the max. Both barcode.pl and Koha::REST::V1::Biblios now call the shared
function, eliminating the duplicated inline code.
Tests: adds EAN-13 test cases to t/db_dependent/Barcodes_ValueBuilder.t
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on.
The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique.
In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors.
Yes.. This tries and solve a bug from 3.8.0 /o/
Test plan:
1 - set syspref "autoBarcode" to generated in the form <branchcode> yymm001
2 - set the barcode field to "barcode.pl" in marc structure
3 - create a new basket
4 - add one item to this basket
5 - click on the barcode field -> it should have a barcode
6 - click on add item and click on the new barcode fiels, it should have
the same value
APPLY PATCH:
7 - click on the barcode field -> it should have a barcode
8 - click on add item and click on the new barcode fields, it should have
an higher barcode.
Note : The barcode is incremented each time the barcode with an empty
value is clicked on. Therefore, if the
librarian removes the value from barcode and click again, they could get
another barcode. I do not know if it is an issue.
Note: This patch is not splitted in two parts anymore
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan, works as advertised.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This can certainly be improved to adjust the permissions, but at least
they are no longer opened to the world..
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Set 'autoBarcode' to something other than 'don't generate automatically'
2. If the a framwwork make sure some 952 fields have the barcode.pl plugin enabled
3. Add a new item and click the '...' next to the 952 field with the barcode.pl plugin enabled.
4. The screen jumps back to the top, annoying.
5. Apply patch
6. Try again, it should not jump anymore!
Signed-off-by: Barbara Johnson <barbara.johnson@swbell.net>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use event parameter instead of id.
This is part of the refactoring happening in bug 30975
Test plan:
1. Verify that the plugin continues to work as before
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The idea rely on the KohaDates TT plugin for the date formatting. We
should not have any output_pref calls in pl or pm (there are some
exceptions, for ILSDI for instance).
Also flatpickr will deal with the places where dates are inputed. We
will pass the raw SQL value (what we call 'iso' in Koha::DateUtils), and
the controller will receive the same value, no need to additional
conversion.
Note that DBIC has the capability to auto-deflate DateTime objects,
which makes things way easier. We can either pass the value we receive
from the controller, or pass a DT object to our methods.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The selector is not correct, we must to not rely on the number.
This patch fixes a regression caused by bug 28445, but also a
long-standing bug.
* Regression:
The barcode plugin is broken is autoBarcode=<branchcode>yymm0001
There is a JS error in the console:
Uncaught TypeError: form.field_value is undefined
Focustag_952_subfield_p_878344
Focustag_952_subfield_p_878344_handler
jQuery 11
BindEventstag_952_subfield_p_878344
* Long standing bug:
If there are several item forms on the same page, the branchcode is not
correctly retrieved. For instance on the "Serial edition" page there are
2 item forms, the homebranch that is used by the barcode plugin will be
the one from the last form.
Test plan:
* regression
Set autoBarcode=<branchcode>yymm0001
Catalogue a new item, click into the barcode input
Notice that without this patch you get a JS error in the console
* long standing bug
Create a new subscription, select "Create an item record when receiving this serial".
Receive a serial
Open the 2 item forms ("Click to add item")
Select 2 different home library and click the barcode inputs.
The prefix (branchcode) should be correct with this patch applied.
QA Note: it would be way easier if all add item forms were using the new
methods, it could be:
let loc = document.getElementsByName('items.homebranch')[0].value;
Yes, that's all!
Signed-off-by: Hayley Pelham <hayleypelham@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should remove the debug statements or use Koha::Logger when we want
to keep it.
Test plan:
Confirm that occurrences of remaining occurrences of DEBUG need to be
kept (historical scripts for instance)
Confirm that the occurrences removed by this patch can be removed
Confirm that the occurrences replaced by Koha::Logger are correct
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me, noting a few minor points on BZ.
JD amended patch: replace "warn #Finished" with "#warn Finished", and
put the statement on a single line
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes some minor changes to the JavaScript generated by the
cataloging plugins: <script> "type" attribute removed; single-line
comments converted to multi-line style; obsolete //<![CDATA[ marks
removed.
These changes help the JavaScript conform to current coding guidelines.
The comment style change allows for whitespace in the scripts to be
collapsed by the Template::Toolkit "collapse" filter.
Since the patch makes small cosmetic changes to many files it may be
easiest to test this patch by visually inspecting the changes.
It's also simple to test some plugins which are enabled by default (at
least in MARC21): In the basic MARC editor, the leader, 007, and 008. In
the item editor, subfield d - Date acquired.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Converts item plugins to new style (with builder and launcher).
See also bugs 10480 and 13437.
The following plugins have been adjusted:
barcode_manual.pl
barcode.pl
callnumber-KU.pl
callnumber.pl
cn_browser.pl (Added license statement too)
dateaccessioned.pl
macles.pl
stocknumberam123.pl
stocknumberAV.pl
stocknumber.pl
Test plan:
Connect the plugin to an item field.
Verify that the plugin still works.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested if all plugins compile okay.
Ran most of them thru FrameworkPlugin.t.
Tested them in the item editor.
Note: the form for macles.pl comes up, further hard to test.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan: See Bugzilla.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
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 makes the following cleanup actions for all plugins:
1- Remove sub plugin_parameters. This function is not used.
2- Remove empty plugin or empty plugin_javascript subs.
3- Remove empty Blur, Clic or Focus routines from javascript.
4- Remove pod lines (copy-pasta) only referring to the 3 plugin subs.
5- Remove the last 1; line. It is no longer needed.
Test plan:
Run the unit test t/db_dependent/FrameworkPlugins.t
Test some cataloguing plugins in addbiblio.
Test some item plugins in additem and neworderempty.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I also checked the syntax of all plugins with perl -c.
And checked the pod (if any) with podchecker: Two files still produce a
warning; the follow-up deals with them: unimarc_field_686a/_700-4.pl.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In addition to adding a new barcode plugin, this commit begins
refactoring the barcode generation code using a new module,
C4::Barcodes::ValueBuilder. From the POD:
This module is intended as a shim to ease the eventual transition
from having all barcode-related code in the value builder plugin
barcode.pl file to using C4::Barcodes. Since the shift will require
a rather significant amount of refactoring, this module will return
value builder-formatted results, at first by merely running the
code that was formerly in the barcodes.pl value builder, but later
by using C4::Barcodes.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Implement auto-incrementing EAN-13 barcodes
To make this work, C4::Barcodes::next was modified to call process_tail with
new incremented value so that process_tail can generate correct checksum.
Since process_tail is currenlty not used by any barcodes, this change is safe.
C4::Barcodes is used by addbiblio.pl when adding multiple records, while value_builder
is used in all other cases.
Test scenario:
1. prove t/Barcodes_EAN13.t
2. KOHA_CONF=/etc/koha/sites/fer/koha-conf.xml prove t/db_dependent/Barcodes.t
this will check C4::Barcode implementataion
3. in systempreference change autoBarcode to incremental EAN-13 barcode
4. edit two items of any biblio assigning barcodes and verify that numbers
are increasing. Have in mind that last digit is check digit, and it
doesn't increment, but is calculated from barcode itself. Example with
checksum in brackets: 000000086275[2], 000000086276[9], 000000086277[6]
5. Add Item and verify that it gets assigned next barcode
6. Add & Duplicate item and verify barcode increase
7. Add Multiple Copies and verify that barcode increase for each copy
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Adding - to regexp for matching branch code. Wondering if other characters should not be added too.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Two things are happening.
First, the SELECT does not account for a branchcode greater than 2 chars.
This is fixed by just selecting the final four digits representing the
incremental suffix from the barcode field.
Second, the incremental suffix (4 digits) is not rolling back over to zero when
reaching 9999.
This pattern probably needs help. It should allow for cataloging of 10000 items
per month as is. I would not recommend doing barcode numbering this way, but
need to support it since it is in use in at least one library.
This patch also impliments strict and warnings per Bug 2505
Signed-off-by: Stéphane Delaune <stephane.delaune@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
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 patch depends on my previous one "Begin cleanup on additem" and
fixes one bug introduced in that patch.
Overhaul of additem sections to factor out common pieces especially attributes.
Plugin js vastly simplified and reimplemented in jquery. Performance improved.
Note that a particularly busy cataloging department should still leave
barcode blank for server-side autopopulation to avoid collision.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Failure to pass the $framework parameter by barcode.pl causes
GetMarcFromKohaField to return 0,0 which breaks the value builder. The
patch
submitted corrects this.
This patch is build against the current 3.1.x HEAD, however, this bug
also
affects the 3.0.x codebase and should be applied there as well.
fbcbug 4
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Most Perl scripts (as opposed to modules) do
not need to require Exporter.
No user-visible or documentation changes.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
nela
Martin Renvoize
Tomas Cohen Arazi
Koha Development Team
Baptiste Wojtkowski
Jonathan Druart
Lucas Gass
Julian Maurice
Owen Leonard
Josef Moravec
Marcel de Rooy
Marc Véron
Jonathan Druart
Jared Camins-Esakov
Dobrica Pavlinusic
Sophie Meynieux
Chris Nighswonger
Andrew Elwell
Donovan Jones
Lars Wirzenius
Joe Atzberger
Galen Charlton
Joshua Ferraro