Searchable values in tickets

29 views
Skip to first unread message

Roger Oberholtzer

unread,
Mar 26, 2012, 5:05:55 AM3/26/12
to trac-...@googlegroups.com
Some variables in tickets are links to all occurrences of that item. For
example, the ticket owner or the milestone. Click on those, and a search
is done based on the value of the field. How can I get that for fields I
have added? For example, I have a field that contains a project number.
I would like to click on the project number and initiate a search for
all occurrences of that project number. Is this possible?

--
Roger Oberholtzer

Cooke, Mark

unread,
Mar 26, 2012, 5:12:04 AM3/26/12
to trac-...@googlegroups.com
AFAIK there is no built-in way to do this.

I believe that those links are just generated search queries and I am thinking that you could probably write a Genshi stream filter to look for the right page (ticket?) and then search for your field name and update the streamed value to an href with the right parameters...

Never tred it, though! I did look at the 'clone ticket' which shows the general idea:

http://trac.edgewall.org/wiki/TicketClone#

~ mark c

Roger Oberholtzer

unread,
Mar 26, 2012, 6:30:36 AM3/26/12
to trac-...@googlegroups.com
On Mon, 2012-03-26 at 10:12 +0100, Cooke, Mark wrote:
> > -----Original Message-----
> > From: trac-...@googlegroups.com On Behalf Of Roger Oberholtzer
> > Sent: 26 March 2012 10:06
> > To: trac-...@googlegroups.com
> > Subject: [Trac] Searchable values in tickets
> >
> > Some variables in tickets are links to all occurrences of
> > that item. For example, the ticket owner or the milestone.
> > Click on those, and a search is done based on the value of
> > the field. How can I get that for fields I have added? For
> > example, I have a field that contains a project number.
> > I would like to click on the project number and initiate
> > a search for all occurrences of that project number. Is
> > this possible?
> >
> AFAIK there is no built-in way to do this.
>
> I believe that those links are just generated search queries and I am thinking that you could probably write a Genshi stream filter to look for the right page (ticket?) and then search for your field name and update the streamed value to an href with the right parameters...

They are indeed generated search queries. I would just like to have them
generated for more fields.

> Never tred it, though! I did look at the 'clone ticket' which shows the general idea:
>
> http://trac.edgewall.org/wiki/TicketClone#

I will check this. Thank's for the pointer.

--
Roger Oberholtzer

Ethan Jucovy

unread,
Mar 26, 2012, 12:18:07 PM3/26/12
to trac-...@googlegroups.com
> > I would like to click on the project number and initiate
> > a search for all occurrences of that project number. Is
> > this possible?
> >
> AFAIK there is no built-in way to do this.
>
> I believe that those links are just generated search queries and I am thinking that you could probably write a Genshi stream filter to look for the right page (ticket?) and then search for your field name and update the streamed value to an href with the right parameters...

They are indeed generated search queries. I would just like to have them
generated for more fields.

Are they standard custom fields?  If so, what type are they?  Custom ticket fields automatically get rendered with these query-links in most cases, but not if they have type "text"/"textarea".  All choice fields do get the links though.

Roger Oberholtzer

unread,
Mar 26, 2012, 5:01:46 PM3/26/12
to trac-...@googlegroups.com
On Mon, 2012-03-26 at 12:18 -0400, Ethan Jucovy wrote:
> Are they standard custom fields? If so, what type are they? Custom
> ticket fields automatically get rendered with these query-links in
> most cases, but not if they have type "text"/"textarea". All choice
> fields do get the links though.

They are "text", not "textarea". Fields with names get the search. I
would imagine they are text as well. But they are built in. I gather it
is only custom "text" fields that do not get the search. Is that by
design?

--

Roger Oberholtzer


Ethan Jucovy

unread,
Mar 26, 2012, 5:24:02 PM3/26/12
to trac-...@googlegroups.com
It looks like that is by design, but I'm not sure I understand it.  This feature was implemented in #7562 -- see in particular these comments about not linking custom text fields:


There was some discussion of adding a ``linked_fields`` configuration option that would let users turn on this feature for their own custom text fields, but it looks like it was never implemented.  (I can't find any reference to "linked_fields" in a checkout of the Trac source, and don't see any logic related to that idea in ticket/web_ui.py where the feature is implemented.)

http://trac.edgewall.org/ticket/7562#comment:23 says that "there is no longer a need for a specific option to unlink/link fields" but it's not clear to me why that's the case.  So it might be worth a feature request.

That said, is there a reason you want to use a "text" field instead of a "select"?

Roger Oberholtzer

unread,
Mar 26, 2012, 5:51:56 PM3/26/12
to trac-...@googlegroups.com

I see the statement that text fields should never be linkified. Odd
statement. What does one type into a search box other than text? I can
agree that having it on globally and by default might be a bit much. But
saying that text fields should never lead to a search seems rather
draconian.

>
> There was some discussion of adding a ``linked_fields`` configuration
> option that would let users turn on this feature for their own custom
> text fields, but it looks like it was never implemented. (I can't
> find any reference to "linked_fields" in a checkout of the Trac
> source, and don't see any logic related to that idea in
> ticket/web_ui.py where the feature is implemented.)
>
>
> http://trac.edgewall.org/ticket/7562#comment:23 says that "there is no
> longer a need for a specific option to unlink/link fields" but it's
> not clear to me why that's the case. So it might be worth a feature
> request.
>

The linked_fields would be a useful thing to me.

>
>
> That said, is there a reason you want to use a "text" field instead of
> a "select"?

Some fields, like project numbers, contain non-numeric characters. So I
made them text. Project numbers drop from the sky like rain. They need
to be something one can enter in the ticket as needed. Is there a better
option than text for this?
>

Ethan Jucovy

unread,
Mar 26, 2012, 7:04:40 PM3/26/12
to trac-...@googlegroups.com
On Mon, Mar 26, 2012 at 5:51 PM, Roger Oberholtzer <roger.ob...@gmail.com> wrote:
I see the statement that text fields should never be linkified. Odd
statement. What does one type into a search box other than text? I can
agree that having it on globally and by default might be a bit much. But
saying that text fields should never lead to a search seems rather
draconian.

I agree.  My guess is that they were thinking of fields with large amounts of freeform text, which wouldn't make sense to search for with = operators.  But that seems like what "textarea" fields are for.  For "text" fields, linkification seems pretty likely to be useful.
 
Some fields, like project numbers, contain non-numeric characters. So I
made them text. Project numbers drop from the sky like rain. They need
to be something one can enter in the ticket as needed. Is there a better
option than text for this?

I was wondering if the set of project numbers might be stable enough to use a "select" instead, but if they're dropping from the sky like rain then "text" sounds like the right choice. :)  

The linked_fields would be a useful thing to me.

It would be useful for me too -- I'll try to find time to submit a patch and see where it goes.

In the meantime, Mark's approach (genshi stream filter) is probably the best option.

Mikael Relbe

unread,
Mar 27, 2012, 1:50:55 AM3/27/12
to trac-...@googlegroups.com

Could it be possible to add a new type of custom ticket field; ”keyword” which behaves exactly as the built in keyword field?

Ethan Jucovy

unread,
Mar 27, 2012, 9:59:42 AM3/27/12
to trac-...@googlegroups.com
I've submitted a feature request with a patch, here: http://trac.edgewall.org/ticket/10643

The patch I submitted lets you turn on query-linking for custom text fields with some [ticket-custom] configuration per field.  It can be configured to use the "standard" query-linking method or the per-word style of query-linking used by the built-in "keyword" field.

On Tue, Mar 27, 2012 at 1:50 AM, Mikael Relbe <mik...@relbe.se> wrote:

Could it be possible to add a new type of custom ticket field; ”keyword” which behaves exactly as the built in keyword field?

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to trac-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

Roger Oberholtzer

unread,
Mar 27, 2012, 12:43:16 PM3/27/12
to trac-...@googlegroups.com
On Tue, 2012-03-27 at 09:59 -0400, Ethan Jucovy wrote:
> I've submitted a feature request with a patch,
> here: http://trac.edgewall.org/ticket/10643
>
>
> The patch I submitted lets you turn on query-linking for custom text
> fields with some [ticket-custom] configuration per field. It can be
> configured to use the "standard" query-linking method or the per-word
> style of query-linking used by the built-in "keyword" field.

This sounds great. I will check it out and report back.

>

--
Roger Oberholtzer

Roger Oberholtzer

unread,
Mar 27, 2012, 4:27:28 PM3/27/12
to trac-...@googlegroups.com
On Tue, 2012-03-27 at 09:59 -0400, Ethan Jucovy wrote:
> I've submitted a feature request with a patch,
> here: http://trac.edgewall.org/ticket/10643
>
>
> The patch I submitted lets you turn on query-linking for custom text
> fields with some [ticket-custom] configuration per field. It can be
> configured to use the "standard" query-linking method or the per-word
> style of query-linking used by the built-in "keyword" field.
>

Just tried the link. Works great! I think this will help us organize a
bit of out work. Thanks alot! I never would have figured that change.
>
>
--
Roger Oberholtzer
>


Ethan Jucovy

unread,
Mar 28, 2012, 7:44:21 AM3/28/12
to trac-...@googlegroups.com
Just tried the link. Works great! I think this will help us organize a
bit of out work. Thanks alot! I never would have figured that change.

Happy to help. :-)

Bikeshedding time: do you have any thoughts on what names would be good for the .format options?  In http://trac.edgewall.org/ticket/10643#comment:3 Peter Suter suggested using something more generic than "querylink"/"querylinkwords" so that the same .format specification could be reused for other features like a Batch Modify UI.

But it's hard to come up with good words for this .. my favorite option so far is .format=item (for standard query-linking) and .format=list (for keyword-style query-linking) but "item" seems a little vague there.  Any other possibilities?
Reply all
Reply to author
Forward
0 new messages