Type: Bug Fix
Affects Version/s: None
Fix Version/s: Not version specific
KULRICE-7060 KIM Person Maintenance screen allows a new user to be created with mixed-case or uppercase letters in Principal Name field KULRICE-4533 KIM allows usernames to be entered with mixed case, but the IdentityService searches in lowercase so user can't login KULRICE-4283 IdentityServiceImpl methods convert principal name to lower case before going to the persistence layer but Person maintenance allows upper case principal names. KULRICE-6687 Person lookup isn't case-insensitive in Rice 2.0 KULRICE-4213 Allow principal names in Kim screens instead of only principal Ids KULRICE-7566 Should consider if a principal should be allowed to have a null principal name KULRICE-4229 Principal Id/Name discrepancy on System notifications KULRICE-4248 KimGroupDao assumes Principals in local database KULRICE-6817 Document search by document type doesn't allow wildcards or case insensitive searches KULRICE-4019 allow header block to show initiator person name instead of principal name
The current implementation of case insensitivity in principal names in KIM requires that the PRNCPL_NM column in KRIM_PRNCPL_T be stored in all lowercase (see linked issue for original work surrounding this). This is implemented by a toLowerCase inside of the IdentityServiceImpl.getPrincipalByPrincipalName
Instead we should implement case insenstivity on principal names without requiring the data to be stored lowercase. I think the only effective way to do this in SQL is to do an UPPER on both ends of the query, for example;
SELECT * FROM KRIM_PRNCPL_T WHERE UPPER=UPPER(PRNCPL_NM)
Of course, there are some potential inefficiencies here related to indexing on the PRNCPL_NM column. There are a few ways we could attempt to address this:
1) If someone is implementing on Oracle they can put a function-based index on this column (not sure if mysql supports that or not)
2) We could add configuration parameters that allow implementers to specify whether KIM principal names are stored in all upper or all lowercase.
Of course, if they are going to be overridding the identity service and not storing data in these tables, it doesn't really matter. But that's going to depend on how a particular institution chooses to implement (and I could definitely see certain implementors choosing to store data in this table).