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).

[Christian Boos]

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.

[Christopher Lenz]

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 :)

[Christian Boos]

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.

[osimons]

Related to #5979.

#7258 suggested the alternative of the user in custom query being able to switch the field from select to text as needed, and thereby supporting the full range of 'startswith', 'contains' and so on.

[massimo.b@…]

Today, is it possible to have wildcards in custom queries?

[anonymous]

More possible duplicates: #1901, #13089. The latter has a PoC implementation.

Workaround: query:component~=plugin