Edgewall Software
Modify

Ticket #7558 (new enhancement)

Opened 3 years ago

Last modified 16 months ago

New TracQuery match operator for "contains the word" would be useful

Reported by: meitarm@… Owned by:
Priority: low Milestone: next-major-0.1X
Component: ticket system Version: 0.11.1
Severity: minor Keywords: query keywords exact match
Cc: mmitar@…
Release Notes:
API Changes:

Description

In a number of situations, it's useful to be able to search field values that contain a certain word, not just a certain string (as ~= does). The distinction is essentially a word boundary regex versus an all-inclusive regex. That is, I'd like to be able search like this:

.*\bmyvalue\b.*

where \b is a "word boundary" as defined by the PCRE standards. Right now, using ~=, I can only search like this:

.*myvalue.*

The most pressing use case for such a facility (at least for my projects) is support for "subticket keywords", an extremely flexible technique of associating one ticket with another by using the TracLinks conventions in the keyword field.

For example, to associate a new ticket as a "subticket" of ticket:13, I place #13 in its keyword field. Currently, this can later be extracted with a TracQuery such as [[TracQuery(keywords~=#13)]] however this incorrectly matches #130, #131, and so on. Thus, a word boundary match operator was suggested by Remy Blank later in the same thread.

At first blush, it seems that the TracQuery "mini language" is actually implemented with simple ANSI SQL-based wildcards, which makes implementing word boundary matches non-trivial. I'd imagine one might have to wrap a call to Query.execute that catches the results of a ~= query and then filters these results further (possibly with a decorator?).

Attachments

Change History

comment:1 Changed 3 years ago by osimons

#7374 closed as duplicate.

comment:2 Changed 3 years ago by rblank

  • Milestone set to 2.0

comment:3 Changed 22 months ago by cboos

  • Milestone changed from 2.0 to unscheduled

Milestone 2.0 deleted

comment:4 Changed 22 months ago by Carsten Klein <carsten.klein@…>

see also #8914 for a patch that would allow regular expression matching for all of the available backends.

comment:5 Changed 20 months ago by cboos

  • Keywords keywords exact match added
  • Milestone changed from triaging to next-major-0.1X
  • Priority changed from normal to low
  • Severity changed from major to minor

#9466 was closed as duplicate.

Note that for the specific use case of "subtickets" described above, this could be handled easily by adopting a slightly different convention: instead of referencing #13, you could add #13. for example, and there would be no false positive ("real" SubTickets support will eventually involve a numbering scheme corresponding to #13.1, #13.2, #13.2.1 etc.).

comment:6 Changed 16 months ago by Mitar

  • Cc mmitar@… added
View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as new
as The resolution will be set. Next status will be 'closed'
to The owner will be changed from (none). Next status will be 'new'
The owner will be changed from (none) to anonymous. Next status will be 'assigned'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.