Closed Bug 232176 Opened 16 years ago Closed 16 years ago
Saved searches no longer usable
The usage of saved searches have regressed to a point where I cannot really use them any more: - The Query page no longer has the option to save a query with a name, instead it appear on the bottom of an allready run query.. I don't mind it being added to the allready run query, but why remove it from its right place ? - I cannoot find a way to edit a saved query... Do I really need to kill the saved one and create another..?? - The option to forget a query has been moved away from the query page and onto the allready run query...I don't mind it being added to the allready run query, but why remove it from its right place ? - I no longer have controll over which saved query appears in the footer, instead they now all appear. This means my list have exploded from 5 to around 70. This makes the footer quite un-usable... I normally try and keep a cool temper and file usefull contructive bugreports, but in this case I really feel bugzilla has been downgraded with respect to the saved searches.
You can edit it by running it, then clicking edit, then saving it. Note that the backwards compat code doesn't quite handle that case; see bug 232163. I vote for backing out at least some ofthe UI changes.....
Instead of commenting here, I've posted in n.p.m.seamonkey, addressing the issues that Henrik has raised. Let's move the discussion over there for the moment. Gerv
Previously I could go to the query page and load a saved search to edit it before executing... It was possible to have a "search template" which would be loaded up into the query form and then adjusted to add some specific search terms. (in effect more than one template akin to the "default query") ... how do I do this now? Note that executing the query without adding more restrictive terms is liable to take AGES, as it returns details of thousands of bugs I'm not interested in.
Have a look at my post in n.p.m.seamonkey headed "Alternatives" for some suggestions. In particular, for this issue, a report over all of the variables might be appropriate, if it's always the same variables. Alternatively, you could bookmark the base query, if you generally use one browser. Gerv
There is currently a checkbox: [ ] and remember these as my default search options the query page. Would it be that more complicated for this to become: [ ] and remember this search ( ) as my default search ( ) as [_______________] When editing a saved query, the text box could be pre-filled in with the query name, and the radio button selected, but the checkbox not checked, to allow for easy update of an already saved query... ... as for the existing queries, perhaps the page footer could become something like: (Default Search) [Edit] | My Query 1 [Edit] | My Query 2 [Edit] | ..... ... where the [Edit] is a link to load it into the query form? When in edit mode on an existing saved query there could also be an option (either as a link or a form option) to delete the query. i.e. the "Forget the search 'My Query 1'" link could appear on the edit page as well as on the search page, for easier deletion of an query that takes minutes to run and returns several thousands of bugs...
> Would it be that more complicated for this to become: Yes, it would be more complicated. How much more? Depends how you measure. But what it is, is the top of a slippery slope down to the previous over-complicated UI. In fact, the more sensible UI change would be to move the "default search" link to join the others... > (Default Search) [Edit] | My Query 1 [Edit] | My Query 2 [Edit] | ..... People are already complaining that the footer has got larger now that all queries are visible. This would make it larger still. It would also increase the possibility of the user clicking the wrong link. In my view, the footer is for quick access to run searches (and other places), not for search management. What did you think of my posts in n.p.m.seamonkey? Gerv
I did read it, and I still agree with reporter that this is a fairly major loss of function regarding query management. In fact on the n.p.m.seamonkey, you seem to be the only one that thinks that having to execute a search in order to do anything with it is "simpler". I can't think of any other UI where you are forced to execute an operation before you can delete it from a list or edit it. What if an email client forced you to run all attachments before you could delete the emails? I'm happy to concede the point on the additional option on the standard query form.... in which case, as you say the "remember as default" and "reset to default" options should also disappear from that page. It would be nice if the [Remember Search] as [____________] box is pre-filled with the query name if we got there by editing an old query, as suggested by James Ross on n.p.m.seamonkey. From that thread I learned that some of these problems were predicted beforehand (bug 179339 comment 4), and at least found what bug it was that originally caused this! At the end of the day, I don't really have that much of an issue with the most of the management functions disappearing from the query page, but they should be *somewhere*. Perhaps a dedicated page that for each query has options to Edit, Delete, Run, and "Hide from page footer"... This could be done without taking up any additional screen space by linkifying the "Saved searches" in the page footer to go to the new management page. IMHO, the relevant changes should be backed out as per bbaetz comment 1 until a usable alternative query management UI is available.
> I'm happy to concede the point on the additional option on the standard query > form.... in which case, as you say the "remember as default" and "reset to > default" options should also disappear from that page. Ah yes, I remember now - the reason that didn't move is that "reset default search" _was_ out of place on the buglist. I can't really agree with you about the backout; so far, out of the however many hundred Bugzilla users, I've had two and a half who have indicated unhappiness. (Of course, posting this comment might lead to a flood of other people making themselves known, but...) I'll have a think about some sort of dedicated query management UI. Gerv
This patch is a new template for page.cgi which gives a list of saved searches, and the option to run, edit or forget them. I hope we can get it reviewed and put up on b.m.o., for those people who are having difficultly with the new UI. I'm not budging on the whole linkinfooter business, though ;-) Gerv
I'm going to reiterate here what I suggested to Gerv in IRC which he didn't like. I want the "Page Footer" tab back in the user preferences. Rename it to "Saved Searches". The UI can be different than it used to be. It should include a list of all of your saved searches, links to delete each, load it to the query page for editing, run it, rename it, you name it. And yes, the "link in footer" option should probably come back. Despite how much Gerv hates it, and the fact that I never personally created any query where I didn't turn on "link in footer", I don't think it was a bad thing, I think just the previous UI for dealing with it sucked. I can think of plenty of reasons why someone might want to save a copy of a query but not have it constantly accessible. And no, bookmarks are not the answer to everything, since some people use more than one computer or browser to access Bugzilla.
The patch in this bug is now up on bugzilla.mozilla.org: http://bugzilla.mozilla.org/page.cgi?id=saved-searches.html This implements a similar UI to that which Dave suggests. Gerv
Yes, that page looks good so far! Just needs the option to hide from the page footer, and everyone will be happy! ;-) (I'm with Dave's comment 10 on this - I don't have linkinfooter off on any of my searches, but can see why some people would.) ummm.... and if the name of the query-being-edited could somehow get transmitted to the text box at the bottom of the search results, so that an edit can be completed without having to guess the original name, that could be good too. I'd not appreciated quite how easy it would be to throw such a page together using the new templatised UI... so I'll just vote for the new way rather than a temporary back-out. Just another thought.... ... rather than having a magic query called "(Default Query)", there could be a "set as default" option against each query on this query management page, together with the "Set my default query back to the system default." option. This would allow these also to be removed from the query page, so that there aren't any leftovers from the old UI for people to think "well lets just add another option there" like I did in comment 5.
>And yes, the "link in footer" option should probably come back. ... And no, >bookmarks are not the answer to everything, since some people use more than >one computer or browser to access Bugzilla. Bugzilla's saved searches functionality contains one and one half features missing from bookmarks: the ability to save searches on the server side for use on multiple machines, and site-specific UI (bookmarks have some site-specificity in that they can be categorized, but categories cannot be tied to sites and made more visible when the user browses the site). Bookmarks functionality, on the other hand, contains numerous features missing from saved searches, including categories, multiple display modes (menu, taskbar, sidebar, search results in sidebar), one-command loading of multiple searches, and reload scheduling/notification of changes. Future work in bookmarks is likely to include support for server-side storage as well as bookmarks sharing mechanisms. The latter is particularly interesting because searches are one of the few totally private Bugzilla activities, and sharing them within a group can increase intra-group understanding and efficiency. We can't possibly hope to duplicate the current and future functionality of bookmarks in saved searches, and we shouldn't try. We should instead offer a way to export saved searches to bookmarks (presumably via XBEL) and, after a sufficient period of time has elapsed, remove the saved searches functionality from Bugzilla entirely, simplifying our codebase by removing this redundancy, and leaving us freer to explore and develop features that really should be part of Bugzilla. It goes without saying that we should explore ways of improving bookmarks-Bugzilla integration, especially if the best server-side bookmarks implementation turns out to be a site-specific solution. And short term improvements in the usability of the existing saved searches functionality, like the recent UI simplification and the patch on this bug, are always welcome. But removing saved searches in favor of bookmarks, a better way of doing the same thing, should remain the ultimate goal.
Uhhhh.... I don't think so. You'll never get me to agree to that. At least not until 95% of the browser market supports the server-side bookmarks thing, if even then. I don't use these urls anywhere except when I'm using Bugzilla, there's no reason for them to waste space in my bookmarks menu when I'm not on the Bugzilla site. If I organize them hierarchically such that they aren't wasting menu space, then I can't find them when I need them either without digging. Having them server side will also allow sharing them with others in the near short term. We have patches in the review queue right now to implement shared queries, where you can mark a query public and then it can be reference by a combination of the query name and your email.
As stated in the newsgroups I also like the patch but... I still want the ability to hide links from the footer, that is my main gripe.. Bookmarks and webpages are NOT the solution for the reasons allready stated. Note: I'm not after somehting big, with a built in hierarchi or somehting fancy like that, I just want the old functionality back.
I'm coming around to Dave's idea. We want a new preferences panel called Saved Searches, which looks like this: Link in footer Search page default My Search 1 Run | Edit | Forget [X] ( ) My Search 2 Run | Edit | Forget [ ] ( ) Another Search Run | Edit | Forget [X] (o) Yet Another Run | Edit | Forget [X] ( ) ... (System default) Run | Edit ( ) This makes the search page default always be either the system default, or one of your saved searches - i.e. it's not so special any more. You have a control UI for managing searches, and can add them to or remove them from the footer. At the same time, we should ditch the special "My Bugs" search, and make it (or a more sensible one, if there is one) a default Saved Search that everyone gets when a new account is created. The migration path would be that all existing accounts get one, with linkinfooter turned off if they have mybugslink turned off. Gerv
This UI looks great. Now just add some link to it so we can easily find it. In the prefs page or in the footer.
This adds a prefs panel which allows you to Run, Edit or Forget your saved searches. This is closely based on the stopgap code in patch 1. In time, it'll get expanded to the full vision outlined in comment 16, but this'll do for the next b.m.o. upgrade and developer release, which Dave wants to do ASAP. Gerv
Attachment #140021 - Attachment is obsolete: true
*** Bug 232162 has been marked as a duplicate of this bug. ***
Comment on attachment 142608 [details] [diff] [review] Patch B v.1 Dave: how about it? Gerv
Attachment #142608 - Flags: review?(justdave)
Severity: critical → blocker
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Comment on attachment 142608 [details] [diff] [review] Patch B v.1 We have another bug for adding the link-in-footer checkbox back to this, right?
Attachment #142608 - Flags: review?(justdave) → review+
Fixed. Checking in userprefs.cgi; /cvsroot/mozilla/webtools/bugzilla/userprefs.cgi,v <-- userprefs.cgi new revision: 1.54; previous revision: 1.53 done Checking in template/en/default/account/prefs/prefs.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v <-- prefs.html.tmpl new revision: 1.14; previous revision: 1.13 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/saved-searches.html.tmpl,v done Checking in template/en/default/account/prefs/saved-searches.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/saved-searches.html.tmpl,v <-- saved-searches.html.tmpl initial revision: 1.1 done Gerv
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Bug 236779 added for the linkinfooter issue. Gerv
*** Bug 237543 has been marked as a duplicate of this bug. ***
*** Bug 240472 has been marked as a duplicate of this bug. ***
*** Bug 233584 has been marked as a duplicate of this bug. ***
*** Bug 247139 has been marked as a duplicate of this bug. ***
*** Bug 250519 has been marked as a duplicate of this bug. ***
*** Bug 258037 has been marked as a duplicate of this bug. ***
In the name of all the dupes, I have a couple of questions: 1. When is b.m.o due to get this fix? 2. Is there a way to work-around this issue with 2.17.6? Thanks, Prog.
> 1. When is b.m.o due to get this fix? When we update. Looks like this won't be before Firefox and Thunderbird 1.0, now. > 2. Is there a way to work-around this issue with 2.17.6? Exactly which issue? There's: http://bugzilla.mozilla.org/page.cgi?id=saved-searches.html The only thing you can't fix is linkinfooter, and I don't know of a workaround for that. Gerv
*** Bug 281061 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.