Created attachment 183364 [details] [review] Bug 40176: Add tests This patch adds a new subtest to xt/api.t It ensures that maxLength will appear in the rest api spec file when there is a size constraint at the DB level
Created attachment 183365 [details] [review] Bug 40176: Add maxLength to item spec file Test plan: Apply the "tests" patch first prove xt/api.t => fail Apply this patch => pass
Created attachment 183526 [details] [review] Bug 40176: Add tests This patch adds a new subtest to xt/api.t It ensures that maxLength will appear in the rest api spec file when there is a size constraint at the DB level Signed-off-by: David Nind <david@davidnind.com>
Created attachment 183527 [details] [review] Bug 40176: Add maxLength to item spec file Test plan: Apply the "tests" patch first prove xt/api.t => fail Apply this patch => pass Signed-off-by: David Nind <david@davidnind.com>
Created attachment 183734 [details] [review] Bug 40176: Add tests This patch adds a new subtest to xt/api.t It ensures that maxLength will appear in the rest api spec file when there is a size constraint at the DB level Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Matt Blenkinsop <matt.blenkinsop@openfifth.co.uk>
Created attachment 183735 [details] [review] Bug 40176: Add maxLength to item spec file Test plan: Apply the "tests" patch first prove xt/api.t => fail Apply this patch => pass Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Matt Blenkinsop <matt.blenkinsop@openfifth.co.uk>
Nice work everyone! Pushed to main for 25.11
Nice work everyone! Pushed to 25.05.x
Enhancement not pushed to 24.11.x
usability note: on Kohas with MANY wrong barcodes this change (very strict) prevented it from loading a number of bibilios and that stopped whole Koha department from work for a while: required everyone to fix the barcodes in one day otherwise it blocks the usage.
Also especially barcode-wise: because it wasn't limited before, some libraries used some prefixes to stort the database, for example I saw "temp_barcode:..code..,new:..code.." and other usage like holding some extra info in barcodes, now they get instant requirement to align their database and fix the barcodes in all records otherwise they even won't show in details.tt because API will die. Some of our customers used non-printable barcode for some special codification, and it was something like "MovedBRANCHIDinum12312123" and other customizations, which helped them to sort the books and expand usage of barcode field to something wider. This now requires to re-think how to use barcodes and change business logic, and even more – will require to asap fix of database, and what's worse - manual or some complex batch, because wrong barcodes records won't be shown after 25.05.02 update (and seems 24.11.recent people also getting this issue). This really blocked number of libraries.
As the barcode is varchar(20) in the database, it woudl mean that those libraries in question have updated the field to a different datatype previously, is that correct? Maybe if this causes a lot of issues the barcode field could be extended in the database and in the API by default?
Did you file a separate bug yet?
(In reply to Andrii Nugged from comment #10) > usability note: > > on Kohas with MANY wrong barcodes this change (very strict) prevented it > from loading a number of bibilios and that stopped whole Koha department > from work for a while: required everyone to fix the barcodes in one day > otherwise it blocks the usage. (In reply to Andrii Nugged from comment #11) > Some of our customers used non-printable barcode for some special > codification, and it was something like "MovedBRANCHIDinum12312123" and > other customizations, which helped them to sort the books and expand usage > of barcode field to something wider. This now requires to re-think how to > use barcodes and change business logic, and even more – will require to asap > fix of database, and what's worse - manual or some complex batch, because > wrong barcodes records won't be shown after 25.05.02 update (and seems > 24.11.recent people also getting this issue). > > This really blocked number of libraries. (In reply to Katrin Fischer from comment #12) > As the barcode is varchar(20) in the database, it woudl mean that those > libraries in question have updated the field to a different datatype > previously, is that correct? > Maybe if this causes a lot of issues the barcode field could be extended in > the database and in the API by default? As Katrin says, it sounds like you customized Koha database schemas for your customers, and then experienced problems when you applied this patch, because there was a discrepancy between upstream Koha and your downstream Koha. But that's not an upstream issue. This change is logical for upstream Koha. If you're going to customize Koha downstream, the onus is on you to test your customizations to make sure they work before putting them into a production environment. It's why I typically advise people not to change the database schema downstream. It's too risky.
On a similar note, Andrii, you'll want to look out for bug 40508, as this also sets the maxLength for barcode, but at the MARC Bibliographic framework level. It should only apply to new Koha instances and not existing ones, but still good for you to watch out for that one.
API-related change, no changes required to the manual.