Bug 26539 - Inconsistent case sensitivity around patron attribute code - potential data loss
Summary: Inconsistent case sensitivity around patron attribute code - potential data loss
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-25 17:34 UTC by Andrew Fuerste-Henry
Modified: 2022-11-24 16:56 UTC (History)
4 users (show)

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


Attachments
Bug 26539: Display patron's attributes without case sensitivity (1.39 KB, patch)
2020-10-13 10:40 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2020-09-25 17:34:10 UTC
To recreate:
1 - have a patron attribute with code "TEST"
2 - using import_borrowers.pl, import a patron with "test:1" in the patron_attributes
field of your CSV
3 - load your patron, confirm the value of 1 shows on moremember.pl
4 - click to edit your patron, confirm the value of 1 does not show on memberentry.pl
5 - query the database, SELECT * from borrower_attributes where borrowernumber=[your borrower], see code="test"
6 - update the database, UPDATE borrower_attributes set code="TEST" where id=[your attribute id]
7 - reload memberentry.pl, it now shows a 1

Back at step 4, if we'd saved our patron, that value would have been lost
Comment 1 Katrin Fischer 2020-09-29 18:42:32 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?
Comment 2 Andrew Fuerste-Henry 2020-09-29 19:33:23 UTC
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.
Comment 3 Katrin Fischer 2020-09-29 19:42:21 UTC
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?
Comment 4 Jonathan Druart 2020-10-13 10:40:05 UTC
Created attachment 111523 [details] [review]
Bug 26539: Display patron's attributes without case sensitivity
Comment 5 Jonathan Druart 2020-10-13 10:41:21 UTC
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.