Ticket search by query with auto completion
|Reported by:||shesek||Owned by:||cboos|
|Cc:||ismael@…, leho@…, ethan.jucovy@…|
I was inspired by YouTrack ticket search box and spent the last couple of hours hacking together something similar.
Its based on jQuery UI's autocomplete and uses the regular TracQuery syntax, but with auto complete for field names, operators and (multi) values. Its not as good-looking as YouTrac?, but still, its really neat :-)
The way I implemented this is by making the regular search box a bit bigger, and my functionality is trigged when 'query:' is written. I thought it would be better than cluttering the interface with a separate search box.
That's about it. just write 'query:' in the top-right search box, and start writing a regular TracQuery. You can move around with the arrows and use tab, enter or the mouse to choose an item from the list.
Currently it supports:
- Auto completes the field name (either at the very beginning or after an '&').
- When a valid field name is typed/chosen, or when just one field name option is left in the suggestions, it start suggesting search operators. Those operators are also filtered as you type them.
- Once an operator is written, it suggests values.
- When a valid value is typed/chosen, it suggest you to add more values after a pipe (|).
- Also, in some contexts it lets you choose 'Another field…' and 'Another value…' which simply adds & or | to the query.
A couple more notes:
- I know some people would prefer this to be a plugin and not part of core, but I think it gives much better UX when searching for tickets.
It can completely replace the Custom Query page in most cases, making it much faster and easier to search. You can search using the keyboard alone, or by using some simple mouse clicks.
The current Custom Query interface is great and much more advanced than this, but for simple searches its an overkill - it takes too much clicks and time to make searches.
- I posted this ticket as soon as I got a working version, so it wasn't tested enough yet. I want to hear what you have to say about the idea in general, and what you think about the way I implemented this. I assume changes and fixes will be needed.
- Most of the auto-complete is done on the client-side. When searching in values of some fields (like component), the client downloads a full list of possible values (only when required), searches them and caches them for the next time a search is needed on the same field.
As there aren't usually many values, I thought it would be better to download it once instead of hitting the server with a request every time the user types something.
- Support for custom fields is missing.
- Maybe the 'query:' prefix can be removed so it'll always be enabled? It does raise some questions (when the form is submitted, and the user typed 'status=new', did he mean to search for tickets with that status or just 'status=new' as plain string in the regular search?), but I think its all solvable.
Change History (68)
Changed 3 years ago by rblank
comment:31 in reply to: ↑ 30 ; follow-ups: ↓ 32 ↓ 33 Changed 3 years ago by cboos
- Component changed from general to search system
- Priority changed from normal to high
- Severity changed from normal to critical
- Version set to 0.13dev
Changed 3 years ago by cboos
comment:54 Changed 18 months ago by cboos
- Milestone changed from next-stable-1.0.x to next-dev-1.1.x