https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42221
--- Comment #3 from Martin Renvoize (ashimema) <[email protected]> --- Bug 8425 (merged July 2024) is where the regression crept in, here's exactly what changed: Before Bug 8425, the Click handler called set_barcode(id, true) — with force=true. The JS just wrote '$nextnum' verbatim (as a string). With any 14-digit plus barcodes, like for example those in KTD, $nextnum came out as one more than the max (39999000019194 in KTD) (14-plus-digit, increments each save because the saved 14-digit barcode eventually becomes the new max). Ugly, but it incremented. After Bug 8425, the Click handler passes force=false and routes EAN13 through incrementEAN13($nextnum, offset). That function slices $nextnum to 12 chars and recomputes a check digit, producing a valid-looking 13-digit barcode. But the saved 13-digit barcode (~3.9×10¹²) is always smaller than the KTD 14-plus-digit sample barcodes (~3.9×10¹³), so max(abs(barcode)) never picks up the saved EAN-13. $nextnum stays frozen at the same value every page load → same barcode every time. So the SQL query was always wrong, but before Bug 8425 it accidentally worked because saving a 14-digit barcode would push the max forward. Bug 8425 changed the JS output to 13-digit EAN-13, which broke that accidental increment. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
