[CWD-5480] Searching in Audit Log is Case Sensitive

Type: Suggestion
Resolution: Low Engagement
Fix Version/s: None
Component/s: Audit Log
Labels:
- cleanup-seos-fy25

UIS:
6
Support reference count:
1
Feedback Policy:

Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

Issue Summary

Customer reports that when searching for users in Audit Log, the query is case sensitive. So, varying cases in usernames, displays name and e-mails may cause them not to be found. The same applies for groups.

Environment

Reproduced on

Crowd 3.6 and 3.7
Postgres

Steps to Reproduce

Sample user name: Guest
Access Crowd, got to Audit Logs
In User filter, type 'guest'
Delete the field content and type 'Guest'
Delete the field content and type 'GUEST'

Expected Results

Find the user typed in either lower, upper or mixed cases

Actual Results

User can only be found if the username it is typed exactly as stored.

The query it performs in Postgres use comparison operation LIKE instead of ILIKE.

Excerpt from Postgres log:

[64807]: [565-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG:  execute <unnamed>: select distinct entities1_.entity_name as col_0_0_, entities1_.entity_id as col_1_0_, entities1_.entity_type as col_2_0_ from cwd_audit_log_changeset auditlogch0_ inner join cwd_audit_log_entity entities1_ on auditlogch0_.id=entities1_.changeset_id where entities1_.entity_type=$1 and (entities1_.entity_name like $2) order by col_0_0_ ASC limit $3
[64807]: [566-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 DETAIL:  parameters: $1 = 'USER', $2 = 'Test%', $3 = '11'

Workaround

None at the moment. User name has to be typed in exact casing as it is stored.

mentioned in: Page Failed to load; Page Failed to load

Aakrity Tibrewal made changes - 27/Apr/2025 12:43 PM

Resolution		New: Low Engagement [ 10300 ]
Status	Original: Gathering Interest [ 11772 ]	New: Closed [ 6 ]

Aakrity Tibrewal made changes - 27/Apr/2025 12:39 PM

Labels

New: cleanup-seos-fy25

Dawid Owoc (Inactive) made changes - 03/Feb/2020 1:20 PM

Affects Version/s	Original: 3.6.0 [ 88291 ]
Affects Version/s	Original: 3.7.0 [ 89391 ]
Workflow	Original: JAC Bug Workflow v3 [ 3760570 ]	New: JAC Suggestion Workflow 3 [ 3813742 ]
Issue Type	Original: Bug [ 1 ]	New: Suggestion [ 10000 ]
Priority	Original: Low [ 4 ]
Status	Original: Needs Triage [ 10030 ]	New: Gathering Interest [ 11772 ]

SET Analytics Bot made changes - 21/Dec/2019 12:40 AM

UIS

New: 6

Matt Shelton made changes - 15/Nov/2019 2:55 PM

Remote Link

New: This issue links to "Page (Confluence)" [ 459120 ]

Matt Shelton made changes - 13/Nov/2019 1:47 PM

Remote Link

New: This issue links to "Page (Confluence)" [ 458799 ]

Bugfix Automation Bot made changes - 19/Oct/2019 6:01 AM

Support reference count

New: 1

Edson (Inactive) made changes - 19/Oct/2019 4:09 AM

Description

Original: h3. Issue Summary

Customer reports that when searching for users in Audit Log, the query is case sensitive. So, varying cases in usernames, displays name and e-mails may cause them not to be found. The same applies for groups.
h3. Environment

Reproduced on
- Crowd 3.6 and 3.7
- Postgres

h3. Steps to Reproduce
# Sample user name: Guest
# Access Crowd, got to Audit Logs
# In User filter, type 'guest'
# Delete the field content and type 'Guest'
# Delete the field content and type 'GUEST'

h3. Expected Results

Find the user typed in either lower, upper or mixed cases
h3. Actual Results

User can only be found if the username it is typed exactly as stored.

The query it performs in Postgres use comparison operation {{LIKE}} instead of {{ILIKE}}
{code:java}
[64807]: [565-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG: execute <unnamed>: select distinct entities1_.entity_name as col_0_0_, entities1_.entity_id as col_1_0_, entities1_.entity_type as col_2_0_ from cwd_audit_log_changeset auditlogch0_ inner join cwd_audit_log_entity entities1_ on auditlogch0_.id=entities1_.changeset_id where entities1_.entity_type=$1 and (entities1_.entity_name like $2) order by col_0_0_ ASC limit $3
[64807]: [566-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 DETAIL: parameters: $1 = 'USER', $2 = 'Test%', $3 = '11'
{code}
h3. Workaround

None at the moment. User name has to be typed in exact casing as it is stored.

New: h3. Issue Summary

Customer reports that when searching for users in Audit Log, the query is case sensitive. So, varying cases in usernames, displays name and e-mails may cause them not to be found. The same applies for groups.
h3. Environment

Reproduced on
- Crowd 3.6 and 3.7
- Postgres

h3. Steps to Reproduce
# Sample user name: Guest
# Access Crowd, got to Audit Logs
# In User filter, type 'guest'
# Delete the field content and type 'Guest'
# Delete the field content and type 'GUEST'

h3. Expected Results

Find the user typed in either lower, upper or mixed cases
h3. Actual Results

User can only be found if the username it is typed exactly as stored.

The query it performs in Postgres use comparison operation {{LIKE}} instead of {{ILIKE.}}

Excerpt from Postgres log:
{code:java}
[64807]: [565-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG: execute <unnamed>: select distinct entities1_.entity_name as col_0_0_, entities1_.entity_id as col_1_0_, entities1_.entity_type as col_2_0_ from cwd_audit_log_changeset auditlogch0_ inner join cwd_audit_log_entity entities1_ on auditlogch0_.id=entities1_.changeset_id where entities1_.entity_type=$1 and (entities1_.entity_name like $2) order by col_0_0_ ASC limit $3
[64807]: [566-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 DETAIL: parameters: $1 = 'USER', $2 = 'Test%', $3 = '11'
{code}
h3. Workaround

None at the moment. User name has to be typed in exact casing as it is stored.

Edson (Inactive) made changes - 19/Oct/2019 4:05 AM

Description

Original: h3. Issue Summary
Customer reports that when searching for users in Audit Log, the query is case sensitive. So, varying cases in usernames, displays name and e-mails may cause them not to be found.

h3. Environment
Reproduced on
- Crowd 3.6 and 3.7
- Postgres

h3. Steps to Reproduce
# Sample user name: Guest
# Access Crowd, got to Audit Logs
# In User filter, type 'guest'
# Delete the field content and type 'Guest'
# Delete the field content and type 'GUEST'

h3. Expected Results
Find the user typed in either lower, upper or mixed cases

h3. Actual Results
User can only be found if the username it is typed exactly as stored.

The query it performs in Postgres use comparison operation {{LIKE}} instead of {{ILIKE}}
{code}
[64807]: [565-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG: execute <unnamed>: select distinct entities1_.entity_name as col_0_0_, entities1_.entity_id as col_1_0_, entities1_.entity_type as col_2_0_ from cwd_audit_log_changeset auditlogch0_ inner join cwd_audit_log_entity entities1_ on auditlogch0_.id=entities1_.changeset_id where entities1_.entity_type=$1 and (entities1_.entity_name like $2) order by col_0_0_ ASC limit $3
[64807]: [566-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 DETAIL: parameters: $1 = 'USER', $2 = 'Test%', $3 = '11'
{code}

h3. Workaround
None at the moment. User name has to be typed in exact casing as it is stored.

New: h3. Issue Summary

Customer reports that when searching for users in Audit Log, the query is case sensitive. So, varying cases in usernames, displays name and e-mails may cause them not to be found. The same applies for groups.
h3. Environment

Reproduced on
- Crowd 3.6 and 3.7
- Postgres

h3. Steps to Reproduce
# Sample user name: Guest
# Access Crowd, got to Audit Logs
# In User filter, type 'guest'
# Delete the field content and type 'Guest'
# Delete the field content and type 'GUEST'

h3. Expected Results

Find the user typed in either lower, upper or mixed cases
h3. Actual Results

User can only be found if the username it is typed exactly as stored.

The query it performs in Postgres use comparison operation {{LIKE}} instead of {{ILIKE}}
{code:java}
[64807]: [565-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 LOG: execute <unnamed>: select distinct entities1_.entity_name as col_0_0_, entities1_.entity_id as col_1_0_, entities1_.entity_type as col_2_0_ from cwd_audit_log_changeset auditlogch0_ inner join cwd_audit_log_entity entities1_ on auditlogch0_.id=entities1_.changeset_id where entities1_.entity_type=$1 and (entities1_.entity_name like $2) order by col_0_0_ ASC limit $3
[64807]: [566-1] user=postgres,db=crowd_360,app=PostgreSQL JDBC Driver,client=127.0.0.1 DETAIL: parameters: $1 = 'USER', $2 = 'Test%', $3 = '11'
{code}
h3. Workaround

None at the moment. User name has to be typed in exact casing as it is stored.

Edson (Inactive) made changes - 19/Oct/2019 4:04 AM

Summary

Original: Searching Users in Audit Log is Case Sensitive

New: Searching in Audit Log is Case Sensitive

Edson (Inactive) created issue - 19/Oct/2019 3:57 AM

Assignee:: Unassigned

Reporter:: Edson (Inactive)

Votes:: 1 Vote for this issue

Watchers:: 3 Start watching this issue

Created:: 19/Oct/2019 3:57 AM

Updated:: 27/Apr/2025 12:43 PM

Resolved:: 27/Apr/2025 12:43 PM

Details

Description

Issue Summary

Environment

Steps to Reproduce

Expected Results

Actual Results

Workaround

Attachments

Issue Links

Forms

Activity

People

Dates