Bug 40476 - Limit new item type codes to letters and numbers
Summary: Limit new item type codes to letters and numbers
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords: Academy
Depends on:
Blocks:
 
Reported: 2025-07-23 06:52 UTC by David Cook
Modified: 2025-09-09 23:12 UTC (History)
4 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
Bug 40476: Limit item type codes to letters and numbers (1.90 KB, patch)
2025-07-23 06:55 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2025-07-23 06:52:05 UTC
Item type codes should be limited to letters and numbers.

When you have item type codes with punctuation in them, it can lead to unexpected search result hits. For instance, if you have items with "BOOK" and "E-BOOK", searches for "E-BOOK" will return hits for "BOOK".
Comment 1 David Cook 2025-07-23 06:52:22 UTC
I suspect there are (many) duplicates of this bug but I haven't been able to find them yet.
Comment 2 David Cook 2025-07-23 06:55:13 UTC
Created attachment 184531 [details] [review]
Bug 40476: Limit item type codes to letters and numbers

This patch adds a custom jquery validator method to perform a regex
test on item type codes in the admin module.

Test plan:
0. Apply the patch
1. Go to http://localhost:8081/cgi-bin/koha/admin/itemtypes.pl?op=add_form
2. Try to input an "Item type" like "abc123+
3. Note the input turns red and the message "Invalid pattern" appears.
4. Try to input an "Item type" like "ébook"
5. Note that the input is capitalised, it stays black, and there is no warning
6. Try out more combinations of things you'd like to use as item type codes
Comment 3 Esther Melander 2025-07-23 15:32:44 UTC
Tested and works as described.

Signed-off-by: Esther Melander <esther@bywatersolutions.com>
Comment 4 Marcel de Rooy 2025-07-25 08:32:25 UTC
What about existing item type codes? Or importing them?
Comment 5 Esther Melander 2025-07-25 17:10:37 UTC
I ran a test with with an item type that had an underscore, E_Book, and the item type was retained and appeared to function. Any new item type went through validation and would not save until the punctuation was removed. Some additional testing could be done on this point.
Comment 6 David Cook 2025-07-28 05:41:31 UTC
(In reply to Marcel de Rooy from comment #4)
> What about existing item type codes? Or importing them?

They'll still be problems.

We could possibly try to add some more backend validation and throw errors for invalid item types, but I even that could be bypassed by people inserting directly into the database with migration scripts, so I'm not sure how effective that would be in the end either.

Fixing these problems is quite annoying as well, because you have to update the database and then reindex all affected records, which on a large database can be quite time intensive at the very least. 

I don't have any good answers on this one I think. For now, I thought we could add the client-side validation to try steering things in a better direction. But I'm open to ideas.
Comment 7 Marcel de Rooy 2025-08-04 08:38:35 UTC
(In reply to David Cook from comment #6)
> (In reply to Marcel de Rooy from comment #4)
> > What about existing item type codes? Or importing them?
> 
> They'll still be problems.
> 
> We could possibly try to add some more backend validation and throw errors
> for invalid item types, but I even that could be bypassed by people
> inserting directly into the database with migration scripts, so I'm not sure
> how effective that would be in the end either.
> 
> Fixing these problems is quite annoying as well, because you have to update
> the database and then reindex all affected records, which on a large
> database can be quite time intensive at the very least. 
> 
> I don't have any good answers on this one I think. For now, I thought we
> could add the client-side validation to try steering things in a better
> direction. But I'm open to ideas.

I dont have a strong argument to block this patch. But just being a bit hesitant since it feels doing half the work needed. And we have so much of these things already in Koha. Asking hereby for feedback from others.
Comment 8 Jonathan Druart 2025-09-09 09:59:38 UTC
Yes, I do agree that it's not enough.

Also if punctuation chars are the problem, we should only reject them (eg. "✔❤★" should be accepted, it's not).

Maybe better to simply add a warning if punctuation characters are present instead of rejecting them? It's easy to implement and we don't have to deal with a db rev?
Comment 9 David Cook 2025-09-09 23:12:37 UTC
(In reply to Jonathan Druart from comment #8)
> Also if punctuation chars are the problem, we should only reject them (eg.
> "✔❤★" should be accepted, it's not).

Your example of ❤ for a branch code on previous bug reports did cross my mind when I was thinking about the regex for this, and it led me to expand the range of allowed values to all Unicode letters and numbers. 

I'm not sure that "✔❤★" should be accepted for an item type code though. We could add emojis to the regex, but I'm not sure there's much real world value there to be honest.
 
> Maybe better to simply add a warning if punctuation characters are present
> instead of rejecting them? It's easy to implement and we don't have to deal
> with a db rev?

I'm not familiar enough with jQuery validator to know if that's an option within it, or if it would need to be a separate event handler. 

--

I'm not necessarily opposed to leaving this as In Discussion or closing it. I've already applied it locally and I don't mind carrying this as a local customization. I thought other people would find it useful, but that might not be the case.