Summary: | Inconsistent case sensitivity around patron attribute code - potential data loss | ||
---|---|---|---|
Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrew> |
Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, kyle.m.hall, patrick.robitaille |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: | Bug 26539: Display patron's attributes without case sensitivity |
Description
Andrew Fuerste-Henry
2020-09-25 17:34:10 UTC
What is the expected behaviour here? I'd say we should print an error if you try to load a patron record with non-existing patron attribute codes. And maybe a note on the patron import page about the use of codes? What do you think? If possible, I'd like them to just not be case sensitive at all. We don't generally expect users to have to worry about case on things. Just about the only place in the staff interface where we make them interact with code values is in reports and SQL isn't case sensitive. So that'd mean making memberentry.pl fetch and display those values regardless of case. Hm, yeah, that could also work. I was worried before libraries might have added both cases, but I think we catch that in the extended attributes GUI? Created attachment 111523 [details] [review] Bug 26539: Display patron's attributes without case sensitivity This patch will fix the original issue, but I'd like to be sure it is what we really want here. If we go this way we will certainly need to adjust the batch mod patrons tool as well. Maybe we should fix the case when the attribute is stored instead. |