Bug 40175

Summary: [OMNIBUS] Missing maxLength to REST API specs
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: REST APIAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: dcook, 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:
Circulation function:
Bug Depends on: 40434, 40511, 40512, 40176, 40177, 40178, 40179    
Bug Blocks:    

Description Jonathan Druart 2025-06-18 21:17:21 UTC
We do not specify the maxLength at the REST API specs level, even if the DB has one defined.

Both must match.
Comment 1 Jonathan Druart 2025-06-18 21:20:18 UTC
Bug 40176 - Add maxLength to the item definition


Bug 40177 - Add maxLength to the library definition


Bug 40178 - Add maxLength to the patron definition


Bug 40179 - Add maxLength to the patron's category definition
Comment 3 Andrii Nugged 2025-08-14 10:17:17 UTC
to expand a little on comment from child bug about usability:
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40176#c10)

> 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.


... might also be applicable to other parameters,

so if there will be some strict changes and that make Koha broken
because of not accurate data, our users get stuck even not knowing
why koha started to crash or at least urgently spending all time
fixing bad data, might be massive job, 

at least people should be warned before upgrade much more in advance,

or we should do gradual updates first with warnings (yet that hard
to do if we just rely on length check in API and return API error on mismatch).

(thinking aloud)