Community
Participate
Working Groups
Mylyn used to provide a mechanism for saving Bugzilla searches via the Search (Ctrl+H) dialog. We removed this facility before moving to the common task repository search page in favor encouraging users to create queries. However, the split between uses of queries and searches has been becoming more clear. Queries are good for listing tasks that you want to be aware of on an ongoing basis and that you either need to work on or respond to. Searches are good for getting a quick overview of tasks, for example, all tasks assigned for a particular milestone or time window. While the query mechanism is good for managing day-to-day work, the search mechanism can be useful for getting an overview of tasks for longer-term planning. The problem is that we currently do not have a UI for storing searches. This means that if there are two task repositories that I want to search frequently, or want to use two different searches for one task repository (e.g. by milestone and by component) I have to do manual clicking. We could provide a way of storing searches in order to avoid this. While the UI may be a bit tricky, the underlying mechanism is simple. We either store the search criteria with the workbench preferences or we provide access to searches stored server side, or both.
Given our search UI improvements I think that we should consider this for 3.0
Mik, do you mind if I'll take a crack at the UI or you are saving this for yourself?
I missed the discussion for the proposed UI on the last conference calls. Could you summarize the results and what you have in mind for the UI?
(In reply to comment #2) > Mik, do you mind if I'll take a crack at the UI or you are saving this for > yourself? Mik, are you taking this one yourself? Can you please confirm if that the case.
As discussed on the call providing a clear and simple UI for this will be very tricky. Before we go down any particular implementation path I would like to see a short proposal on the direction. My current thinking is that this is a cross-connector facility that's similar to "Update Attributes". So one approach is that we create another common row that has something like this in it: [ combo for selecting saved v] [X] Save as: [ text box ] [Update Attributes] This will mean two-click selection of a search, but that's probably the best we can do without getting too fancy. The key questions are where this row goes (top or bottom of page) and how it will overlap or be merged with the repository selection row. Also, with the addition of this we might need to add some collapsible sections on the Bugzilla search page because it could get too complex overalll.
(In reply to comment #5) > As discussed on the call providing a clear and simple UI for this will be very > tricky. That is why I don't know how it would look like before working on it. But that is fine if you don't want me to work on this. > Before we go down any particular implementation path I would like to > see a short proposal on the direction. My current thinking is that this is a > cross-connector facility that's similar to "Update Attributes". So one approach > is that we create another common row that has something like this in it: > > [ combo for selecting saved v] [X] Save as: [ text box ] > [Update Attributes] Update attributes button is not going to work in that place, because it is currently NOT cross-connector. Also it doesn't make sense to use screen real estate for the text box for the search name and popup dialog shown on [Save as...] button would take less screen real estate.
Created attachment 90559 [details] bugzilla search
Created attachment 90560 [details] JIRA search
Created attachment 90561 [details] Trac search
(In reply to comment #6) > > Before we go down any particular implementation path I would like to > > see a short proposal on the direction. My current thinking is that this is a > > cross-connector facility that's similar to "Update Attributes". So one > approach > > is that we create another common row that has something like this in it: > > > > [ combo for selecting saved v] [X] Save as: [ text box ] > > [Update Attributes] > > Update attributes button is not going to work in that place, because it is > currently NOT cross-connector. Yes, that will require resolving bug 208153 first which would be good to make the UI more consistent across connectors. > Also it doesn't make sense to use screen real > estate for the text box for the search name and popup dialog shown on [Save > as...] button would take less screen real estate. I am not a big fan of nested modal dialogs but in this case it might be the better way to go to avoid adding more widgets to the crowded search pages. An additional button to delete saved searches would also be needed. Is the search facility going to be scoped by repository or would it show all saved searches?
Another option is to add panel on the right side that could be shown using [>>] button on the right of the "Task ID" filed (sort of similar to the dialog help UI) or we can even show it all the time... Then we'll have enough space to show list of saved searches for selected repository, text entry field and delete button.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
