Opened 17 years ago
Last modified 6 months ago
#5720 new defect
Trac ticket query should be case insensitive. — at Version 6
Reported by: | Lachezar Dobrev | Owned by: | Matthew Good |
---|---|---|---|
Priority: | normal | Milestone: | next-stable-1.6.x |
Component: | report system | Version: | |
Severity: | major | Keywords: | query case sensitive |
Cc: | itamarost@…, alexander.stohr@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
The current implementation of the Trac ticket query system is case sensitive, which is very frustrating.
Searching for Owner=Jonas does not yield the same results as searching for Owner=jonas (whereas Owner=~Jonas and Owner=~jonas do).
This makes it very hard to find your own tickets if your user name is not lowercase, and puts up a lot of problems finding whether there is already an entered ticket on a specific subject.
Change History (6)
comment:1 by , 17 years ago
Milestone: | → 0.11.1 |
---|
comment:2 by , 16 years ago
Milestone: | 0.11.2 |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
comment:3 by , 15 years ago
I also have case sensitive searches. I use a mySQL database and have found that this behaviour is caused by the 'COLLATE' method specified when creating the Trac database.
When I created the Trac database I executed the following command:
CREATE DATABASE trac DEFAULT CHARACTER SET utf8 COLLATE utf8_bin
The "COLLATE utf8_bin" part at the end tells mySQL to compare strings using a binary comparison, which as you would expect compares the actual ASCII character codes - so 'a' is different to 'A'. To make searches case insensitive I should have used:
COLLATE utf8_general_ci
which makes mySQL compare strings in a non-binary way.
To fix this I manually modified all the text fields in the database to use the utf8_general_ci method (it's in the column details tab when viewing table properties).
comment:4 by , 13 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
I also came across the issue of TicketQuery being case-sensitive (I'm running 0.12.1), and found this ticket stating that it is not the case (at least back then).
It seems that even on current t.e.o the TicketQuery is case-sensitive. Following are two query examples, the first one returning 3 results, the second one returning zero results.
[[TicketQuery(max=3,owner=cboos)]]
:
[[TicketQuery(max=3,owner=CBoos)]]
:
No results
comment:5 by , 13 years ago
Description: | modified (diff) |
---|---|
Milestone: | → next-minor-0.12.x |
Seems the difference comes from "contains" vs. "equals". The former is case insensitive ,the latter not.
I've fixed the ticket description accordingly.
Worksforme here on t.e.o, and in my local test environments (SQLite, MySQL and PostgreSQL), with 0.11-stable.
If someone can reproduce the issue, please reopen with detailed information about the setup.