Summary: | [OMNIBUS] Missing maxLength to REST API specs | ||
---|---|---|---|
Product: | Koha | Reporter: | Jonathan Druart <jonathan.druart> |
Component: | REST API | Assignee: | 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
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 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) |