Bug 19113 - Barcode value builder not working with numeric branchcode
Summary: Barcode value builder not working with numeric branchcode
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor with 2 votes (vote)
Assignee: Blou
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-15 15:03 UTC by Blou
Modified: 2019-06-18 13:01 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 19113 - Barcode value builder not working with numeric branchcode (1.82 KB, patch)
2017-08-15 15:11 UTC, Blou
Details | Diff | Splinter Review
Bug 15685: DBRev 17.06.00.014 (2.90 KB, patch)
2017-10-11 22:48 UTC, PTFS Europe Sandboxes
Details | Diff | Splinter Review
Bug 19113: Barcode value builder not working with numeric branchcode (1.82 KB, patch)
2018-05-23 17:52 UTC, Blou
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Blou 2017-08-15 15:03:14 UTC
The regexp for the value builder 'hbyymmincr' doesn't allow for numerics in the branchcode, so the nextnum found is always 0 and multiple Add always generate the same barcode.
Comment 1 Blou 2017-08-15 15:11:51 UTC
Created attachment 66019 [details] [review]
Bug 19113 - Barcode value builder not working with numeric branchcode

The regexp for the value builder 'hbyymmincr' doesn't allow for numerics in the branchcode, so the nextnum found is always 0 and multiple Add always generate the same barcode.

This simply allow for numerics within the regex.

Test
- It's a bit complicated.  You need
   - all your branchcodes to be numerics (01,02,71...)
   - all barcodes to already be a bunch of numbers
- Modify the syspref 'autobarcode' to hbyymmincr, the home branch + date one.
- Find an item in the pro-search,
- New -> New Item
- Click on the 'p' to have the value builder create the next barcode.
   - Without the patch, the query won't have found anything, so it'll suggest xxxxxx0001
- Click Add.  It reprensent the form to enter another one.
   - Click on the 'p' edit box, it'll offer you again xxxxxx0001
With the patch, it'll offer valid ones everytime.
Comment 2 PTFS Europe Sandboxes 2017-10-11 22:47:50 UTC
Patch tested with a sandbox, by Jon Knight <J.P.Knight@lboro.ac.uk>
Comment 3 PTFS Europe Sandboxes 2017-10-11 22:48:18 UTC
Created attachment 67981 [details] [review]
Bug 15685: DBRev 17.06.00.014

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Comment 4 Marcel de Rooy 2017-10-13 09:14:59 UTC
Please correct the attachments here and add proper signoff line
Comment 5 Blou 2018-05-14 19:06:45 UTC
Comment on attachment 67981 [details] [review]
Bug 15685: DBRev 17.06.00.014

patch 15685 for bug 19113.  Sounds wrong.
Comment 6 Blou 2018-05-23 17:52:38 UTC
Created attachment 75509 [details] [review]
Bug 19113: Barcode value builder not working with numeric branchcode

The regexp for the value builder 'hbyymmincr' doesn't allow for numerics in the branchcode, so the nextnum found is always 0 and multiple Add always generate the same barcode.

This simply allow for numerics within the regex.

Test
- It's a bit complicated.  You need
   - all your branchcodes to be numerics (01,02,71...)
   - all barcodes to already be a bunch of numbers
- Modify the syspref 'autobarcode' to hbyymmincr, the home branch + date one.
- Find an item in the pro-search,
- New -> New Item
- Click on the 'p' to have the value builder create the next barcode.
   - Without the patch, the query won't have found anything, so it'll suggest xxxxxx0001
- Click Add.  It reprensent the form to enter another one.
   - Click on the 'p' edit box, it'll offer you again xxxxxx0001
With the patch, it'll offer valid ones everytime.
Comment 7 Blou 2018-05-23 17:57:00 UTC
Still don't understand why the patch had been replaced by Bug 15685.  So setting back to need sign off.  Not signed off yet.
Comment 8 Mark Tompsett 2018-05-23 21:41:04 UTC
(In reply to Blou from comment #6)
> Test
> - It's a bit complicated.  You need
>    - all your branchcodes to be numerics (01,02,71...)

Who sets their branch codes to purely numerical values?!


>    - all barcodes to already be a bunch of numbers
> - Modify the syspref 'autobarcode' to hbyymmincr, the home branch + date one.

Support for the hbyymm barcode methodology has been deprecated, as far as I know. Why even fix it for this bizarre case?
Comment 9 Mark Tompsett 2018-05-23 21:50:22 UTC
Comment on attachment 75509 [details] [review]
Bug 19113: Barcode value builder not working with numeric branchcode

Review of attachment 75509 [details] [review]:
-----------------------------------------------------------------

::: C4/Barcodes/ValueBuilder.pm
@@ +49,4 @@
>      my $month = $args->{mon};
>      my $query = "SELECT MAX(CAST(SUBSTRING(barcode,-4) AS signed)) AS number FROM items WHERE barcode REGEXP ?";
>      my $sth = C4::Context->dbh->prepare($query);
> +    $sth->execute("^[-a-zA-Z0-9]{1,}$year$month");

If this regexp is wrong, there are several other places it is wrong too. See C4/Barcodes/hbyymmincr.pm db_max for example.

See also line 142:
This format is deprecated and SHOULD NOT BE USED.
Comment 10 Katrin Fischer 2018-05-24 05:57:34 UTC
We have branchcodes that are a mix of capitals and numbers, so I don't think it's an odd case.

The problem with deprecating something just in the source code is that people will still use it - how would they know? The code comments have been there forever, maybe we need to fix it or remove it, but don't leave it like that? Least we could do is add a note to the GUI about it being problematic or deprecated.
Comment 11 Blou 2018-07-20 14:58:56 UTC
I'm biased and in full agreement with Katryn here.

The code does exist and is in use.  And there is certainly no good way to deprecate it.  So why not just fix it.  It's a few adjustments in the code, one patch to push, some or many users happy.

There are many valid reasons to refuse an enhancement, and some good reasons to refuse a fix (ugly, could break other things, badly engineered...).  But I don't think deprecation is valid, unless there's a plan behind it.

What is the suggested PRACTICAL alternative for the user at this point?
Comment 12 Mark Tompsett 2018-07-20 15:19:34 UTC
(In reply to M. Tompsett from comment #9)
> If this regexp is wrong, there are several other places it is wrong too. See
> C4/Barcodes/hbyymmincr.pm db_max for example.

You can't just fix this place then. Fix them all. And include a full test plan. I'll look at it if all places are fixed, and I remember to get back to this.