Closed Bug 232176 Opened 16 years ago Closed 16 years ago

Saved searches no longer usable...

Categories

(Bugzilla :: Query/Bug List, defect, blocker)

2.17.6
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: henrik, Assigned: gerv)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Assignee: justdave → gerv
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
Attached patch Patch v.1 (obsolete) — Splinter Review
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
Attachment #140021 - Flags: review?(justdave)
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.
Attached patch Patch B v.1Splinter Review
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. ***
Duplicate of this bug: 250519
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.