#25382 closed enhancement (invalid)
trac: "port is foo" query should match ticket with Port: foo bar
| Reported by: | swebster@… | Owned by: | wsiegrist@… |
|---|---|---|---|
| Priority: | Low | Milestone: | |
| Component: | server/hosting | Version: | |
| Keywords: | trac | Cc: | wsiegrist@… |
| Port: |
Description
Ideally if you perform a query for "Port" "is" "someport" then this will return tickets which have "someport" as one of the listed ports in the "Port:" field. Currently if a ticket has two or more ports listed, eg. "someport anotherport" then the query will not match. Not particularly important.
I set the component as "server/hosting" even though the guide told me not to because that's how all the other trac tickets were categorized. Also guessed maintainer was wsiegrist since he was always the assignee.
Change History (5)
comment:1 Changed 14 years ago by wsiegrist@…
comment:3 Changed 14 years ago by wsiegrist@…
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
You got what you asked for. If you want tickets where the port field _contains_ "someport", then use the _contains_ match instead of _is_. If you click on "Ticket Query" in the left nav bar, it will setup a query for you.
comment:4 Changed 14 years ago by sewebster@…
Right, I understand the mechanism of the current behaviour. However, based on my logic, when you choose to use the "port is" query, you really want to find any ticket which matches that specific port name you enter. You might do this for instance if you wanted to find all tickets filed against "poppler" but NOT "poppler-data". However, the current system would cause you to not find a ticket which is filed against "poppler" and "gtk2" for instance if you used "port is poppler".
I guess what I think would be better would be more difficult to implement, and might necessitate stuff like searching for "babl AND gegl" if you wanted to perform the same query that currently happens when you use "port is babl gegl". Of course currently searching for "port contains gegl babl" will also not find #20906 which I also think is non-optimal.
Anyway, as I said, this is not important. Hopefully you at least understand what I am getting at, but you are of course free to disagree :) Probably good advice for people in general is to usually not use the "is" option, and to make your "contains" queries rather "vague" to start and only narrow down if necessary. Maybe this is obvious.
comment:5 Changed 14 years ago by wsiegrist@…
You should file an enhancement request for a new match type to the Trac Project
Can you provide example URLs for a ticket and a query that you think should work differently? The Ticket Query works how you are asking for it to work as far as I can tell.