Support LIKE and wildcards in custom queries

[koegl@…]

For many fields (component, version, milestone, ...) only "is" and "is not" are present as options in the filter combo box. For my application I would need at least "like" (processed as SQL's LIKE) in addition to that.

Without this capability I cannot currently dispense with the report modules (which, as I read, is being phased out in favor of the query module).

[cboos]

Related to #548, in particular this comment.

[anonymous]

I discovered that you can achieve a "begins with" (and other) component name match already today, using the query language in specially written URLs: simply use a query string part like "...&component=^blah-&..." and you'll have a selection of all tickets whose associated component starts with "blah-". The only catch is, indeed, that the relevant syntax "=^" (and =~, =$, plus the negations) is erroneously documented (cf. http://trac.edgewall.org/wiki/TracQuery) as "^=" (and ~=, $=, ...). (Or perhaps the documentation is correct but the implementation isn't.)

So it would seem to be a simple matter of adding a "begins with" entry into the combobox, and have this translate to a "=^" in the generated query string.

[cmlenz]

What do you components/milestones/versions look like that you need substring matching as opposed to using simple ORs as are already provided by the UI?

[anonymous]

Replying to cmlenz:

What do you components/milestones/versions look like that you need substring matching as opposed to using simple ORs as are already provided by the UI?

They look like so: Major1-Minor11, Major1-Minor12, Major1-Minor13, Major2-Minor21, Major2-Minor22, ..., Majorx-Minory, ... And I would like to custom-query all tickets whose, e.g., associated component begins with "Major2-". As I said above, I can do it via an URL but I cannot do it using the GUI. That alone seems to be a good reason for complementing the current GUI's combobox entries (IMO).

[shansen@…]

For the record, I'd find this feature very useful, too.

Replying to cmlenz:

What do you components/milestones/versions look like that you need substring matching as opposed to using simple ORs as are already provided by the UI?

For our part, we use a single Trac instance for more then development tracking. We like keeping them together so they can interact readily when needed-- but we'd like to keep them apart in other ways. Naming schemes are helpful in that.

Development milestones are like "Release-4.1.5", "Release-4.1.6", etc. An installation may be "Install-Sitename 4.1 upgrade".

Being able to search on everything for a milestone LIKE "Release-%' would rock. Components do something similar, though to a lesser degree. OR can accomplish the end, but is very cumbersome, especially for milestones. We can go edit all the saved-queries everytime a milestone is created, but its a pain :)

[cboos]

Replying to shansen@advpubtech.com:

Being able to search on everything for a milestone LIKE "Release-%' would rock. Components do something similar, though to a lesser degree. OR can accomplish the end, but is very cumbersome, especially for milestones. We can go edit all the saved-queries everytime a milestone is created, but its a pain :)

One alternative would be to have multiselect fields, like Redmine has {look for the + sign below value listbox). That would at the same time reduce the difficulty to enter more than one value for a given criterion and it would be fast to select all the Release-... entries in one gesture. Note that nothing would change for selecting the first value for a criterion.