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
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.