Bug 40175 - [OMNIBUS] Missing maxLength to REST API specs
Summary: [OMNIBUS] Missing maxLength to REST API specs
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 40434 40511 40512 40176 40177 40178 40179
Blocks:
  Show dependency treegraph
 
Reported: 2025-06-18 21:17 UTC by Jonathan Druart
Modified: 2025-08-14 10:17 UTC (History)
3 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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)