Bug 40176

Summary: Add maxLength to the item definition
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: REST APIAssignee: Jonathan Druart <jonathan.druart>
Status: RESOLVED FIXED QA Contact: Matt Blenkinsop <matt.blenkinsop>
Severity: enhancement    
Priority: P5 - low CC: david, dcook, fridolin.somers, matt.blenkinsop, nugged, tomascohen
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
25.11.00,25.05.02
Circulation function:
Bug Depends on:    
Bug Blocks: 40175, 40433, 40177    
Attachments: Bug 40176: Add tests
Bug 40176: Add maxLength to item spec file
Bug 40176: Add tests
Bug 40176: Add maxLength to item spec file
Bug 40176: Add tests
Bug 40176: Add maxLength to item spec file

Description Jonathan Druart 2025-06-18 21:18:43 UTC

    
Comment 1 Jonathan Druart 2025-06-19 09:20:23 UTC
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
Comment 2 Jonathan Druart 2025-06-19 09:20:25 UTC
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
Comment 3 David Nind 2025-06-26 07:38:37 UTC
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>
Comment 4 David Nind 2025-06-26 07:38:40 UTC
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>
Comment 5 Matt Blenkinsop 2025-07-03 10:05:59 UTC
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>
Comment 6 Matt Blenkinsop 2025-07-03 10:06:01 UTC
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>
Comment 7 Lucas Gass (lukeg) 2025-07-08 21:45:08 UTC
Nice work everyone!

Pushed to main for 25.11
Comment 8 Paul Derscheid 2025-07-10 20:50:48 UTC
Nice work everyone!

Pushed to 25.05.x
Comment 9 Fridolin Somers 2025-07-31 12:23:17 UTC
Enhancement not pushed to 24.11.x
Comment 10 Andrii Nugged 2025-08-14 09:00:08 UTC
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.
Comment 11 Andrii Nugged 2025-08-14 11:40:53 UTC
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.
Comment 12 Katrin Fischer 2025-08-16 11:26:48 UTC
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?
Comment 13 Katrin Fischer 2025-08-16 11:27:39 UTC
Did you file a separate bug yet?
Comment 14 David Cook 2025-08-18 00:59:29 UTC
(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.
Comment 15 David Cook 2025-08-18 01:04:54 UTC
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.
Comment 16 David Nind 2025-08-30 00:22:52 UTC
API-related change, no changes required to the manual.