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.
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.
Patch tested with a sandbox, by Jon Knight <J.P.Knight@lboro.ac.uk>
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>
Please correct the attachments here and add proper signoff line
Comment on attachment 67981 [details] [review] Bug 15685: DBRev 17.06.00.014 patch 15685 for bug 19113. Sounds wrong.
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.
Still don't understand why the patch had been replaced by Bug 15685. So setting back to need sign off. Not signed off yet.
(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 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.
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.
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?
(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.
Looks like still valid. Should also impact C4/Barcodes/hbyymmincr.pm
I looked through the code and I believe we can delete the second instance. I removed the db_max method from the hbyymmincr.pm file and tested to see if the correct barcode is generated when the patch is applied, and everything seems to be working fine. I don't think there is any other barcode that follows the hbyymmXXXX format. If someone could also go through the process on their side (remove the db_max method and check if the full test works), it would allow us to delete the method without any issues. The test plan is the same as before: 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.