[KULRICE-6687] Person lookup isn't case-insensitive in Rice 2.0 Created: 10/Feb/12  Updated: 06/Sep/12  Resolved: 09/May/12

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.0.2
Security Level: Public (Public: Anyone can view)

Type: Bug Fix Priority: Critical
Reporter: Chitra Chandran Assignee: Jeremy Hanson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to KULRICE-6556 Rice Dev: Principal ID search on Pers... Closed
Similar issues:
KULRICE-5249Case Insensitive flag ignored in KNS
KULRICE-6817Document search by document type doesn't allow wildcards or case insensitive searches
KULRICE-6556Rice Dev: Principal ID search on Person lookup is case sensitive
KULRICE-11712Suggest queries should be case insensitive
KULRICE-4165Search on document description should be case insensitive
KULRICE-85implement case-insensitive searching
KULRICE-7060KIM Person Maintenance screen allows a new user to be created with mixed-case or uppercase letters in Principal Name field
KULRICE-7624Results from person lookup should be bounded by default like it is in Rice 1.x
KULRICE-5694Under some circumstances lookups can return the same row multiple times
KULRICE-2407finish Person Lookup and Inquiry
Rice Module:
KAI Review Status: Not Required
KTI Review Status: Not Required


We are seeing a couple of things w.r.t Person Lookup:

1. Lookup using principalName - principalName fieldValue is always converted to lowercase before the actual search (which is case-sensitive always). So, this lookup only works for database values that are in lowercase. If we have principal names with mixed case or uppercase, the search fails.

2. Lookup using other fields - These are case-sensitive now.

When I looked at the code, the difference I see is that the actual search happens thru CriteriaLookupDao which does not have the case-insensitive logic like LookupDao does.

Comment by Matt Sargent [ 10/Feb/12 ]

Chitra, which version of rice 2.0 are you using?


Comment by Chitra Chandran [ 13/Feb/12 ]

Hi Matt, I was testing using RC1 release

Comment by Jeremy Hanson [ 17/Feb/12 ]


Comment by Jeremy Hanson [ 17/Feb/12 ]

I thought we started enforcing lower case principal names in 1.0.x?

Comment by Jeremy Hanson [ 17/Feb/12 ]

so questions.

KC has principalNames that are mixed case? We have enforced lower case since 1.0.1. I believe our documentation says that you need to override the identity service to implement it with mixed-case. Are you doing this?

If you add wildcards to the search, it won't be case-sensitive. Is that a problem, or is there a reason case-insensitivity is needed?

Comment by Jessica Coltrin (Inactive) [ 20/Feb/12 ]

This seems to not be a bug, so I'm resolving. Please reopen if there is a need.

Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Comment by Ken Geis [ 27/Mar/12 ]

I don't think this should have been closed. Case-sensitive search on person names (first and last, not principal) make search difficult. This is a real implementation problem for us since usability-wise, we've found search to be a weak point in Rice. I would like for my users to be able to search people in a case-insensitive way without needing to use wildcards.

Comment by Matt Sargent [ 09/May/12 ]

Eric was going to bring this up to the KTI, but after some research here's what we've found...

In the name fields (first, middle, last) are case insensitive. So if you search first name for Eric, ERIC, eric, erIC, etc. you get the same results. In 2.0 you only get the expected result if you search for Eric.

So there is a bug that needs fixed on those name fields.

Comment by Eric Westfall [ 09/May/12 ]

And in terms of Jeremy's earlier comment. This is in regards to first name, last name, etc. not the principal name.

Comment by Kristina Taylor (Inactive) [ 15/May/12 ]

This is now working for KC as of our latest Rice upgrade.

Generated at Sat May 30 00:11:34 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.