Roundup Issue Tracker's search page is based on URL parameters selected from a form. It can use some enhancements:
- Result format selection
- Using named queries in URL
- Advanced URL editing
- Better search list display
The implementation will modify existing templates or create new templates. Programming new actions and changing schemas and detectors written in Python will be required.
Details
The Roundup Issue Tracker has the ability to specify searches and save them. Roundup currently ships its default tracker templates with a table format for search results. However other output formats can be provided. For example a chart template format, or a kanban template format can be used. The current search forms don't support choosing a template for the results.
A search is represented as a URL with multiple query parameters. This works well, however:
- the URL can get long, this may cause issues with maximum URL length
- sharing the URL via email, slack, chat etc is cumbersome
Using a form to generate a search query is a good starting point. But tweaking the search URL or debugging the URL is difficult. Editing the URL in the browser's address bar is possible, but not fun. For advanced users, displaying the search URL in a text-area where it can be edited and resubmitted improves the advanced user experience. For example:
/issue?status=unread,in-progress,resolved&
keyword=security,ui&
@group=priority,-status&
@sort=-activity&
@filters=status,keyword&
@columns=title,status,fixer
is much easier to edit than one long line in the address bar.
Managing a lot of saved queries can be difficult. Saved queries are displayed on the left side of the page.
Saved queries are ordered by name. You can always choose to name your query "001 my query", "002 another query" etc., but this is awkward. Users can also share queries (make them public). These shared queries can be displayed, but user displaying the query doesn't own and can't change the name of the query. Also one user may want the query at position 5 and another may want it at position 25. So a single sort order on the query doesn't make sense.
One way to handle this is to adding a query_order property
for the user's profile. The user can list the query id's in the order
they want. This is a lot of work if you have 60 queries but you only
want 5 at the top of the list for fast access. If the character
'*' shows up in the list, any queries that are not
explicitly ordered are displayed at that location. For example a value
of: "1,2,3,*,22,34" will display queries: 1, 2, 3. Then
it will display all unhidden queries that are not in
"1,2,3,22,34" in normal sort order by name. Lastly
queries 22 and 34 will be shown.
With 60 queries, the list gets long and takes up space.
Similarly a max_queries property added for the user can
restrict the list of queries to the first max_queries
entries and the additional queries can go into a select box with
a search button to display that search.