https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |francois.charbonnier@inlibr | |o.com, | |philippe.blouin@inlibro.com Assignee|koha-bugs@lists.koha-commun |philippe.blouin@inlibro.com |ity.org | Patch complexity|--- |Trivial patch Status|NEW |Needs Signoff Severity|enhancement |minor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 PTFS Europe Sandboxes <sandboxes@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |sandboxes@ptfs-europe.com --- Comment #2 from PTFS Europe Sandboxes <sandboxes@ptfs-europe.com> --- Patch tested with a sandbox, by Jon Knight <J.P.Knight@lboro.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 --- Comment #3 from PTFS Europe Sandboxes <sandboxes@ptfs-europe.com> --- Created attachment 67981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=67981&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #67981|0 |1 is obsolete| | --- Comment #5 from Blou <philippe.blouin@inlibro.com> --- Comment on attachment 67981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=67981 Bug 15685: DBRev 17.06.00.014 patch 15685 for bug 19113. Sounds wrong. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 --- Comment #6 from Blou <philippe.blouin@inlibro.com> --- Created attachment 75509 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75509&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #7 from Blou <philippe.blouin@inlibro.com> --- Still don't understand why the patch had been replaced by Bug 15685. So setting back to need sign off. Not signed off yet. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 --- Comment #11 from Blou <philippe.blouin@inlibro.com> --- 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? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Sukhmandeep <sukhmandeep.benipal@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sukhmandeep.benipal@inLibro | |.com --- Comment #14 from Sukhmandeep <sukhmandeep.benipal@inLibro.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com Status|Needs Signoff |Failed QA --- Comment #15 from David Nind <david@davidnind.com> --- I had a go at testing, but I notice no difference before and after the patch is applied. I don't really understand what has actually changed here, or what the issue is that this fixes - since I can't replicate the issue. Testing notes (using KTD) ========================= Before the patch ---------------- 1. The latest/highest value barcode in the sample data is 39999000019193. 2. Set the autoBarcode system preference to "generated in the form <branchcode>yymm0001". 3. Add a new item to a record and click in the "p - Barcode field:": ==> Result: the barcode generated is CPL24120001 4. Add another item to the record and click in the "p - Barcode field": ==> Result: the barcode generated is CPL24120002 I can't replicate the problem originally reported: "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." The results are what I expected - the barcode in the new pattern increments by 1 for new items, CPL24120001, CPL24120002, CPL24120003, and so on. If I delete all the barcodes (1. Access the database: koha-mysql kohadev 2. Remove all the barcodes: update items set barcode=NULL;) and add a manual barcode, such as 35, the barcodes still increment as expected from CPL24120001. If I use the "Add item", "Add and duplicate", and "Add multiple copies of this item", and also add n item to another record, I can't replicate the issue as described. After the patch --------------- I reset everything so that the changes made to the data before the patch are gone. 1. The latest/highest value barcode in the sample data is 39999000019193. 2. Set the autoBarcode system preference to "generated in the form <branchcode>yymm0001". 3. Add a new item to a record and click in the "p - Barcode field:": ==> Result: the barcode generated is CPL24120001 4. Add another item to the record and click in the "p - Barcode field": ==> Result: the barcode generated is CPL24120002 I noticed no change in behavour or results. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes the generation release notes| |of item barcodes, where the | |autoBarcode system | |preference is set to | |"generated in the form | |<branchcode>yymm0001" and | |the library code is either | |a number or alphanumeric | |value. This automatically | |generated barcode format | |didn't work in this case, | |and the number generated | |would not automatically | |increment. --- Comment #19 from David Nind <david@davidnind.com> --- (In reply to William Lavoie from comment #17)

Hi David,

Have you changed the branchcode for a numerical value? I tried on KTD, using the following steps : 1- koha-mysql kohadev 2- update items set barcode=NULL; 3- change one of the barcode to any numerical value 4- update branches set branchcode = 1 where branchcode="MPL"

Note that for the last command you might receive a warning. Then, when creating a new item I put Midway for both the Home and Current library (I chose Midway but any library will do, it just has to be the same as the one with the numerical branchcode) and I was able to reproduce the problem.

I've retested - it was my error! I didn't read the bug properly, and didn't get that this is about library codes that have numeric or alphanumeric characters. How I tested: 1. Create a new library with a library code that is a number: - Administration > Basic parameters > Libraries > + New library - Library code: 001 - Name: Library 001 - Submit 2. Create a new library with a library code that is alphanumeric: - Administration > Basic parameters > Libraries > + New library - Library code: LIB1 - Name: Library 1 - Submit 3. Set the autoBarcode system preference to "generated in the form <branchcode>yymm0001". 4. Find a record with one item (any record will do): - Edit the current item: . Change the home library and current library to Library 001 (library code is 001) . Empty the "p - Barcode field:" . Click in another field . Click back in the "p - Barcode field:" . Generates barcode 00125020001 . Save changes ==> Result: successfully saves - Add another item to the same record: . Change the home and current library to Library 001 (library code is 001) . Click back in the "p - Barcode field:" . Generates barcode 00125020001 (note that it isn't incremented) . Add item ==> Result: Error saving item: Barcode must be unique. 5. Repeat step 4 for another record with one item, but use Library 1 (library code is LIB1): - Edit the current item: . Change the home library and current library to Library 001 (library code is 001) . Empty the "p - Barcode field:" . Click in another field . Click back in the "p - Barcode field:" . Generates barcode LIB125020001 . Save changes ==> Result: successfully saves - Add another item to the same record: . Change the home and current library to Library 001 (library code is 001) . Click back in the "p - Barcode field:" . Generates barcode LIB125020001 (note that it isn't incremented) . Add item ==> Result: Error saving item: Barcode must be unique. 6. Repeat for an existing library that has a library code with only alpha characters (Centerville Public Library, CPL): ==> Result: works as expected . First barcode is: CPL25020001 . Second barcode is: CPL25020002 7. Apply the patches and RESET everything (reset_all) . Note: this clears all the changes made, need to set autoBarcode system preference . Alternative is just to restart everything (restart_all), and note that the barcodes generated will be the next in the sequence, not necessarily 0001 and 0002 8. Repeat step 4 (Library 001, library code 001): ==> Result: Now works as expected . First barcode is: 00125020001 . Second barcode is: 00125020002 9. Repeat step 5 (Library 1, library code LIB1): ==> Result: Now works as expected . First barcode is: LIB125020001 . Second barcode is: LIB125020002 10. Repeat step 6 (Centerville Public Library, CPL): ==> Result: No change, continues to work as expected . First barcode is: CPL25020001 . Second barcode is: CPL25020002 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 William Lavoie <william.lavoie@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178026|0 |1 is obsolete| | --- Comment #21 from William Lavoie <william.lavoie@inLibro.com> --- Created attachment 178028 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178028&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178028|0 |1 is obsolete| | --- Comment #22 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 178132 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178132&action=edit 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. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 --- Comment #24 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|25.05.00 |25.05.00,24.11.08 released in| | Status|Pushed to main |Pushed to stable --- Comment #26 from Fridolin Somers <fridolin.somers@biblibre.com> --- Pushed to 24.11.x for 24.11.08 This change should be covered by a unit test in t/db_dependent/Barcodes_ValueBuilder.t -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19113 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #28 from David Nind <david@davidnind.com> --- Bug fix, no change to the manual required. -- You are receiving this mail because: You are watching all bug changes.