Closed Bug 16775 Opened 25 years ago Closed 20 years ago

Optional simplified query interface (query.cgi)

Categories

(Bugzilla :: Query/Bug List, enhancement, P2)

Product:
Bugzilla
Component:
Query/Bug List
Version:
2.13
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Bugzilla 2.20

People

(Reporter: zow, Assigned: myk)

References

(Depends on 1 open bug,
URL
)

Details

Attachments

(19 files, 2 obsolete files)

Try this out and see if you like it.
12.22 KB, text/plain
Details
This is the HTML generated by the above attachment
28.51 KB, text/html
Details
A patch query.cgi - made to look easier
27.13 KB, text/plain
Details
HTML to show how it will look
22.40 KB, text/html
Details
The diff file. (Hope this works)
7.36 KB, patch
bbaetz
: review-
Details | Diff | Splinter Review
Update to my original change html sample
32.70 KB, text/html
Details
Medium Query at http://www.ags.uni-sb.de/~afranke/mozilla/query.html
24.16 KB, text/html
Details
New Query Page Sample HTML (non-functional)
27.24 KB, text/html
Details
Query Help Sample HTML (non-functional)
24.09 KB, text/html
Details
query.cgi perl file patch - please merge with new javascript.
27.69 KB, text/plain
Details
queryhelp.cgi Perl file *NEW* - place in bugzilla dir
22.50 KB, text/plain
Details
new queryhelp.cgi
64.06 KB, text/plain
Details
diff -u against current cvs
16.32 KB, patch
bbaetz
: review-
Details | Diff | Splinter Review
The Query Page
22.14 KB, text/html
Details
Query Help Page
63.21 KB, text/html
Details
New Queryhelp.cgi
64.15 KB, text/plain
Details
queryhelp.cgi updated to say that query.cgi will appear in later version of bugzilla
64.54 KB, text/plain
Details
HTML output of queryhelp.cgi
77.44 KB, text/html
Details
another approach to a simple query page
4.65 KB, text/html
Details 
I'm a newbie to Mozilla and for being in pre-beta, it's very impressive, but it
has its rough spots. I'd submit bug reports on these, but I find it hard to

believe that no one else has. I've tried querying the bug reports, but I've
never found any matches. I figure the problem is user error b/c the query

tool is too difficult to use if you're not an active developer. All I know is
that I'm running M10 under Linux. I don't know what component my problem

could be coming from, or what severity someone else may have classified it at.
Most importantly, I think the reason that I'm not finding any bug reports is

because the engine is looking for substrings in the descriptions, not keywords
(which is all I can think to search by). Would it be possible to add a "quick

search" to the query tool that could just search the entire database for keyword
matches?
I'm sorry you find it confusing, but I'm not sure what to do to help you.  There
really isn't a concept of "keywords" in bugzilla, so your suggestion doesn't
make much sense.

Don't be afraid to submit a duplicate bug.  I understand that it may be work
that you don't want to do, but you shouldn't have to worry about making more
work for the receiver of the bug.  It's better to have the same bug reported
twice than not at all.
It's not a long time ago that I was faced with that query form for the first
time myself, so I know what you're talking about, and I might be able help you
get started with it.

To get some results for a start, try the following:
- go to bugzilla.mozilla.org
- click on "Query existing bug reports"
- deselect NEW, ASSIGNED and REOPENED from Status so that nothing is selected on
any of the top selects
- scroll down to URL and enter "www.deja.com" or just "deja"
- click on "Submit Query"
This should bring a list of bugs that have "www.deja.com" (or "deja") as part of
their URL field.

If you have problems with a specific site you might try a query like that to see
if somebody has reported it before.

Some other tips:
- Look at bug reports to get a feel for the type of things people enter in the
Summary, Description, URL and Status whiteboard fields (which you'll probably be
using most)
- See http://bugzilla.mozilla.org/bug_status.html for info on the various fields
in the query form
- See http://www.mozilla.org/bugs/ and
http://www.mozilla.org/newlayout/bugathon.html for a few tips on using bugzilla
and some ready-to-run queries (and to join BugAThon!)
- Forget about the Platform, OpSys, Priority, Severity, Program, Version,
Component and Target Milestone fields to get started. If you're just looking for
possible earlier reports for a bug you can do without those fields just fine.
- Practice :)

That's all I can think of right now, hope it helps!
zow, there is an easy-to-miss line at the bottom of the
Query form, just under the[Submit] button:
"Give me a clue about how to use this form." which takes you to:
http://bugzilla.mozilla.org/help.html
The page there is actually helpful.

terry, a tiny, tiny RFE: just a bit of whitespace above the "Give me a clue"
line would make it *much* more visible.


As for what the fields mean, on the query page, most of
the important field names are links to pages describing
the meaning of each of the options.

Also, as for duplicate bugs, if you follow the guidelines in
http://www.mozilla.org/quality/bug-writing-guidelines.html
it should be easy to see if your report is a DUP,
but even if it is, the work you do to write it up well
could easily uncover a new way of looking at the problem,
or a clear and useful testcase.

At worst, if your report adds nothing to what is already known
and reported in a bug report that yours is resolved as a DUP of,
you will learn information from that report that will be valuable
if you find other related bugs and want to report on them.
Thanks for the responses guys - deselecting the fields was what I was really
looking for. The clue was probably sufficient, but I did totally miss it.

Being stuck between the submit button & the long links below it, the eye tends
to go right over it. Perhaphs that link could be given some
<em>phasis. I guess
that automatically selecting one of the fields in a list if none are specified
by the form is a Mozilla pecularity. There's one to test my new found bugzilla

skills on. . . For the record, I wasn't confused about what the values in the
lists meant (except for all the components), I was just unsure what someone

else may have put there in any of the reports I was looking for.
So the only action I can think of that should be taken to resolve this bug is
making that "clue" link easier to see.
I'll second the proposed solution to this bug: make that "clue" link more
visible.

Hate to admit it but I'd missed it too..
Status: NEW → ASSIGNED
Priority: P3 → P2
The attachment I just uploaded is called 'simplequery.cgi', and is a scaled
down versin of the query page.  It has a "Power Search" link at the bottom
that goes to the real query page.  The "real" way to do this would probably
be to add a parameter to query.cgi to determine whether you wanted the simple
or full query page, but it might be difficult, since the proposed layout here
would mean merging a couple of the tables if the simple query were chosen.
I did this as a quick hack, since I had users screaming at me about it being
too complicated on my site. :)

Well, that's pretty nice looking, I must admit.  

I dread all the infighting that this will cause.  I anticipate zillions of
comments along the general lines of "What!  I have to use the advanced page just
to query by priority?!?!?  That's so lame!"  Where, of course, everyone wants
just one more thing added to the simple page, and they all want something
different ...

This would be greatly reduced if I had a mode per user which remembered which
kind of query page they last saw, and made query.cgi display that page by
default.  Then, the advanced users would stop ever seeing the simple page, and
the beginning users would never see the complicated stuff until they ask for it.
I really like the idea of having a user preference for which query page they'd

rather use (and of course, a link on the query page to change it).  I've already

got a good start on this due to the complaints I got here, as far as merging the

two query CGIs together and switch based on a parm in the URL right now.  I am,

however, horrible at mucking with SQL databases, so if you can handle adding the

user preference and a way to change it on their password/prefs screen I'll see

if I can fix query.cgi to use it.  But I'll warn you it may be a few weeks.

We're about this[]close to a milestone release and we're aiming for next week,

with our main product, but there's still stuff to finish up. :) I think for

forward compatibility, this preference should be stored either as a string or

an integer, and not a boolean, in case for some reason even more layouts for

the query page get defined...


I agree completely about using a preference for this, accessible through
http://bugzilla.mozilla.org/changepassword.cgi, and also on either search
form (saved to the user record if the user is logged in, for persistence).

dave@intrec.com, could you please make available the HTML generated by the
Perl you posted, as an attachment or at a URL, with the form ACTION deleted,
if that's advisable? I'm not quite able to visualize the page from reading the
Perl.  I am currently drafting a "Beginner's guide to searching for previously 
reported bugs" meant for linking from the Bug Writing Guide. The first 
instruction is currently to ignore everything above "Program:" for the first
search, and I'd guess that your form would change all that.

Dave - I like that simple query a lot better. I think as we're getting closer to

a Netscape branded beta, that will be the type of search that more and more

users will want. The developers will certainly want to continue to use the

advanced search, and for that, I think a preference setting would be useful. One

note on the simple query: leave off the version - that doesn't make any sense to

me and I've been using Mozilla for months now. I think of the version as M10,

M11, M12, etc. or one of the daily builds. When I look at the version offerings

in the query forms, it seems to me that they haven't been updated in a year or

so, although I imagine that they make sense to the developers.










I got that comment from one of my testers as well...  That having the version

number there was still confusing.  OK, so we nuke the version number (have it

default to searching all of them).  I'm assuming the Component selection should

still stay there.



Also, I'm all for moving the "give me a clue" link to the top of the form, so

they see that first without having to scroll down.


I'll second moving the clue, and maybe adding a <strong> tag to it.

I think nuking the version number is acceptable as if I want to see if others
have this problem, I'm not going to have a clue what version it showed up in,
just what the current status is.

Two observations:

(1) For users who would be best served by a simple search form, effectively
combining the Summary and Description entry fields would probably help more
than it would get in the way. That way the user would not have to try the
same search twice if one or the other did not have the keyword being searched
for ... and realistically, many don't make multiple searches before concluding
that the bug has not already been reported. The Summary field, and possibly
the Description entry field, could still be left for those who find the list
too long, and want to try another search without moving to the full query page.

(2) The Keyword field is not terribly useful on the Simple search form: 
attempting to seach for an arbitrary keyword like "Scrollbar" will result in:
  >Please stand by ... 
  >Unknown keyword named scrollbar. 
  >The legal keyword names are listed _here_. 
... which is apt to scare off some searchers from trying further. The problem
is overloading of the word "keyword". It is being used here to mean "controlled
vocabulary keyword", but most beta testers, if they have even heard of such,
will think of the bare word "keyword" (as opposed to something like "title
keyword" or "subject keyword") as a free-text keyword. The Description entry
field much more closely resembles that, and a new field added for bug 1749
would match that expectation, natural for someone whose database searching
has been limited to web search engines and library catalogs, even better.

Note that this isn't just academic: in bug 24334, under 
 -- Additional Comments From vidiot@vidiot.com  2000-01-21 --,
it can be seen that this confusion over what the Keyword field searches 
*has* happened.

So I would advocate removing the existing Keywords field from the Simple
search form, and adding, if creating what is asked for in bug 1749 is feasible,
a field that searches the Summary and Description in parallel.

I feel pretty strongly that things done from the simple search should not only
be simple to specify, but simple to execute, too.

Searching the description entries is *expensive*.  At bugzilla.mozilla.org,
there are currently 171,457  entries in that database table, summing to a total
of 45,168,705 bytes!  There is no magic to help; once you've narrowed down a
query by virtue of the other fields, it just has to grind through all the
possible descriptions.

I'm leaning towards simplifying the simple query by dropping the "A description
entry" field from it entirely.

PLEASE NO!!!  I use the description field query all the time.  Often to find 
bugs where folks have not filled in the info into URL of keyword field.

zow, this is a great query system.  I can find almost anything.  But you have 
to know how to use it.  I do not think it is confusing, and would be happy to 
help you if you e-mail me directly with your question leger@netscape.com.

Also, terry, I could right a "How to Use the Query Page" doc which would help 
lots of folks.  Would you like me to do that?
> PLEASE NO!!!  I use the description field query all the time.  Often to find 
> bugs where folks have not filled in the info into URL of keyword field.

I said "simplify the simple query".  The full query page would continue as it is
today, complete with the full-text search.  I was just talking about the
proposed simple query page (that you can view by clicking on the second
attachment of this bug).

> zow, this is a great query system.  I can find almost anything.  But you have 
> to know how to use it.  I do not think it is confusing, and would be happy to 
> help you if you e-mail me directly with your question leger@netscape.com.

I take it you're answering the original bug report here...

> Also, terry, I could right a "How to Use the Query Page" doc which would help 
> lots of folks.  Would you like me to do that?

Of course!  The more documentation, the better.

I would prefer a document that wasn't tied down to our particular installation. 
There are now many installations of Bugzilla (at least 50, I suspect more than
200), and it would be great if they could all benefit from your documentation
too.

Thanks!
(Adding Jan to the CC list, so that she'll know to go read the comment I just
added.)
leger: (you know, keeping track of names beyond email addresses would be nice,
especially since my real name is Terry too, but that's for another report) As
Terry said, we're only talking about simplifing the simple query. My original
report stemmed from a dual problem:
1. There was a bug in M10 on Linux with form selection that was causing me to
search the null set of reports and
2. I missed the "Get a clue" link which I think is suffcient documentation for
any developer (not necessarily a Mozilla developer) to figure out how to use the
query tool. Perhaphs it could be improved as more people (that don't have a
software development background) start to use Mozilla and submit bugs, but I'm
not going to worry about it. Like terry said, more documentation is always good.

I would like the simple query tool simpily as a time saver so I can just quickly
find all the bugs that sound like mine and then try to determine by hand if any
of them are exactly the same. I'm not interested in doing anything fancy, like
doing correlation between reports to try to find deep seated bugs. At least not
with Mozilla.

I would like a single field search that searched both the summary and
description fields. This would probably require doing keyword indexing of the
description fields (there we go overloading the use of keyword again: by keyword
I mean anything that isn't isn't an article, pronoun or otherwise useless in a
search string), then doing a table lookup of the words in the description to
find the best matches. Essentially what the web indexers like Altavista do, only
across the bug database.


ok, how about if we let the search be expensive...   Just have the "search

summaries" field, with a checkbox next to it for "also search descriptions (note,

this may take a while)" or something like that.


Because that's not very simple.  This is a fine idea to add to the expert query
page, but that verbiage will just confuse novices.

(See my above comment about "infighting"?  It's coming true already! :-)

And yes, adding word search database horsepower to let you search long
descriptions is a good idea.  It's also real work.
So, terry, what are your thoughts on this today?  Do you not want to have a 
simpler query page at all, or are you still considering ideas for what a simple 
query page should be?

New testers people complain about how hard the query page is to use almost every 
day on #mozillazine.

I think the boolean charts are a great, but since they are buried within the old 
stuff, they don't make the query page easier to use.

I still think making a simple query page similar to the attachments on this bug
would be a great idea.  I think of it as completely different than the boolean
charts.  (IMO, the boolean charts are an *advanced* feature, since the UI gives
you absolutely no clues on what kinds of reasonable values you can type in the
text field.)

I still want to do this.  I just wanted to get boolean charts done first,
because I think there are implementation details (nothing visible to the UI)
where the two features may interact.
Hi all, hope you don't mind me joining the CC list.  This is a very interesting

bug to me, because it is the perfect counterpart to bug 11328.  That is, where

11328 was about creating an advanced query screen, this bug is about

improving/simplifying the simple query screen.  Indeed, it does seem like the

query screen is very difficult to do right, for some reason.



I am also strongly in favor of having a preference setting to allow the user to

decide whether he wants the simple or the advanced query screen as his default,

and I like the idea of having a link to the advanced screen on the simple screen

(as the second attachment proposes).


See the super dooper new bug #31144 for a proposal which would allow this and
more.
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Would it make sense to have one simple query page for non-developer users, one 
for bugzilla trolls, and one for developers?  On advantage of this is that 
developers could have status set to {new|assigned|reopened} and end-users could 
have resolution set to {not resolved|fixed|duplicate}.
I think Bugzilla is BY NATURE, mainly a developer's tool to begin with.  I don't

like the idea of "dumbing it down" for end-users.  Don't get me wrong--I am

mainly also an end-user at the moment, but I think Bugzilla is quite useful

without catering to us.  In fact, I think Bugzilla would become less useful if

it lost its focus on what it is originally designed to be: a tool that enables

the DEVELOPERS to track the bugs through their lifecycle.


That does make some sense: end users can user Netscape's form or toss their 
bugs into the "bug day" discussion (#mozillazine/irc.mozilla.org, tuesdays).
I think it would help a lot it there was a piece of text saying that unmodified 

field don't limit the search. This information should be conspicuously visible at 

the top of the query form.
Status: NEW → ASSIGNED
This is currently discussed on n.p.m.qa.general .



A possible approach for full-text search: how about submitting a GOOGLE search 
request? it will require a method for google to read all bugs (e.g. a linked-
list of pagss, 10 bugs each, scanning entire DB, referenced from the ROBOT.TXT 
file). It won't be up-to-date, but will give a great power.
(Actually, my initial thought after reading this thread was to treat the entire 
description as keywords, but I think letting Google do it is better...)
Here is a patch which I designed to look easier. Notice the HTML sample I 
included does not have the same options as you regularly see because my server 
didn't have the same options chosen. On the bugzilla server it should have all 
the options. I moved the clue to the top, added a link, and put headers on all 
the sections. I also made each section easier to look at. I even made the 
boolean chart easier to follow as it doesn't head off into infinity in the x 
direction. I have tested it on my server.
Alternately, you could remove the outside borders on the tables.
This looks quite good to me; a few niggles, but they can wait until other people 
have looked at the general idea. Can someone put up query.cgi as a diff?

Gerv
I thought it wasn't necessary because it was a webtools file. I will do that 
for you. :-)
I also think this looks much better, but please remove the table borders - they
are ugly.

And one minor detail: I think at least a <br> or better a <p> would be appropriate
after the "Reset" button and before the "Log in as someone besides ..." link.
The following has been finished:
-Removed tables.
-Added the <p> after Submit query button at the bottom of the page.
-Fixed inclusion/exclusion options.
-Made the page collapse a little better when the horizontal width is changed.

I will post a sample html file.
Note I will not post the re-modified source immediately so people can criticize 
more.
If you want a sample of the changes, contact me on IRC (I will be asleep for 
the next 12 hours probably though).

Note that I expanded the boolean table. That is to show you what it looks like 
expanded.
I like the advanced query and/or stuff, it should be better.
This bug and the discussion in bug 61561 are related: Both are about making it
easier to query Bugzilla. They are complementary in that this bug (and bug
41654) are about improving and simplifying the graphical query form (query.cgi,
with select boxes, radio buttons, checkboxes etc.) whereas bug 61561 is about
adding an alternative text-based one-line simple-search form to the bugzilla
front page. You are invited to take part in the discussion over there.

My (hopefully constructive) comments about the proposal in this bug:
- It fixes bug 61972 and puts the "clue" link at the top, that's great.
- It avoids putting the OR'd expressions all on one line, that's great.
- I don't like some of the sections and their headlines: 
  * Bug Settings / Module Options:
    Well, in my view Platform/OpSys and Product/Component are more closely 
    related than e.g. Platform/OpSys and Status/Resolution. Where is the logical 
    division between fields about the bug itself (Product/Component/Platform/
    OpSys) and fields about the process of fixing it (Severity/Priority/Status/
    Resolution)? Ok, arguably severity could belong to both.
    Summary, URL, would logically belong to the first group, 
    Status Whiteboard, Target Milestone, Votes to the second.
    But it's probably not wise to tear the text fields apart.
  * Email Options: ++
    An alternative for this would be "People involved". (I'd prefer this.)
  * Inclusion/Exclusion Options: --. 
    I can't see any reason why these options constitute a section at all. 
    Actually, it should be two sections: (1) bug numbers
    and (2) changes. I don't see the value of (1), or why it can't be on a 
    separate form (when do you want to exclude some bug numbers??) 
    Otherwise, these are just some more additional conditions, just like 
    everything else.
  * Text Search Options:
    Oops, where is the keywords field?
  * Boolean Chart: +
    Would it be possible to have it by default expanded one step in both 
    directions (OR and one of AND and Chart)? Would this cause either functional
    or usability problems? The advantage would be that you would immediately get
    and idea of how it works, without having to click on several buttons.

One problem this doesn't solve is that you have to scroll down for the search
button.
Oops, of course I meant you have to scroll down for the submit button...
BTW, I can't seem to find the "Target Milestone" field?
Right, the target milestone is missing. It's only part of the boolean chart
now.
The keywords field is probably missing because I don't have bugzilla set up 
100% like it is on bugzilla.mozilla.org I believe. I am going to take a look 
and see if I can figure out what MySQL setting I need to add. 
Yeah. There is a MySQL table called Keywords that I guess you have to place 
entries into to get that part of the cgi to work. Since I am on Win2k, I have 
not fully configured Bugzilla because Bugzilla uses groups which is 
incompatible with Win32 Perl (Why I don't know - Win2k has groups). Therefore, 
a lot of the configuration CGIs say that I am not a member of so and so group 
and don't give me access. Therefore, don't worry - if you see things missing 
they are most likely still in the CGI. It is just I haven't fully configured 
Bugzilla. 

BTW: I hope when Hixie releases Bugzilla 3.0 he implements the groups without 
relying on the OS or getgrnam perl function.
For portability of Bugzilla, see: bug 62287 

Andreas: 

I believe you are saying in your first comment that you think there is no 
logical division between the fields on Bugzilla. Although I couldn't move all 
the fields around, I think that is valid and something that should be looked 
into for future versions of Bugzilla. Perhaps you could submit a bug on that if 
one doesn't already exist.

I personally think bugzilla should be changed eventually to look more like 
www.redhat.org/bugzilla, but if I changed that on query.cgi, all of bugzilla 
would have to be changed.

Your other suggestions can be done.
Your boolean chart comment would be possible I believe if people want this, but 
I would like to know others' opinions on this first. I am not entirely sure 
what the limits are on the Exlude/Only bugs numbered option. Is it possible to 
write ranges? If that is the case then it definately has to do with the other 
choices as you could say "Choose these changes", but exclude the first 1000 
bugs. If not, then maybe ranges should be added. I did change the Email Options 
to People Involved as I don't think that is really a big deal.
I liked the borders. I vote that they come back :-)

Small niggles:

Under Pick Bug Settings, you might say "Click on a heading for a description of 
that setting/category/control (pick one word"

Put "Changed to value (optional) plus its text box to the right of "Where the 
following fields changed" and reduce the text to "To".
So:  Where the following fields changed [ List ] To (optional) [ Text box ] 

Change "Summary" to "Bug summary" (clarity) and "URL" to "Associated URL"

Move "What is this chart" up near the words "Boolean chart"

Start with fewer boolean charts.


Other than that, cool ;-)

Gerv

To take a look at the progress of my changes, you can always go to:
http://www.netdemonz.com/webtools/bugzilla/query.cgi

Just a warning: It might occasionally be down. If the server is down, it means 
that I have probably taken my laptop (yes its on a laptop) somewhere. If the 
cgi isn't working then I am probably in the middle of making changes.
Just a status report: If you go and look at the page so far, you can click the 
links to the help page I'm making. (BTW: the help page uses CGI). 

Gerv: I am still planning to implement your niggle changes. Just haven't gotten 
around to it yet.
Blocks: 65931
OK. I'm finally finished. I created a new query page and a help page. I will 
show both in HTML, but they won't be functional. I will also attach the Perl 
afterwards. As tara (I think) updated the javascript in Bugzilla, they need to 
be merged with the new javascript. If I am correct, this can be used on the new 
version of Bugzilla that is coming out very soon (not 3.0)
Please ignore the fact that the Banners didn't appear. The problem is I saved 
these files in IE and should be punished. Oh please be easy on me :-0
> I believe you are saying in your first comment that you think there is no 
> logical division between the fields on Bugzilla. Although I couldn't move all 
> the fields around, I think that is valid and something that should be looked 
> into for future versions of Bugzilla. Perhaps you could submit a bug on that 
> if one doesn't already exist.

Filed bug 66090 about this issue. "Modular Query Page Design: Separate info
about the bug from info about the bug fixing process"

Brian, your help page seems a bit verbose and lengthy to me. I have only read
the beginning and the end, though. I would prefer a shorter one, but that's my
personal opinion.
Your "query.cgi perl file patch" is not a patch, but the actual file...  anyone 
got a diff?  :)

Can you please talk to me on IRC? I have a question. I'll be posting the diff 
soon.
Attached patch Query.cgi diff (obsolete) — — Splinter Review 

    
    

    
  
BTW: the query.cgi here is outdated, so please don't use it. Queryhelp.cgi is 
fine though. I have no idea how to add new files to a diff so please use the 
one here.

    
    

    
  
BTW (sorry) the diff is fine, but the actual query.cgi listed is outdated.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        diff -u against current cvs (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
I couldn't get the diff Brian posted to apply.  'patch' kept rejecting it.  I 
took Brian's original query.cgi file, applied all of the changes listed in Bonsai 
since he says he checked out the original, and created a new patch with that.

I have it live at http://www.a2central.com/~justdave/bugzilla if anyone wants to 
play with it (although there's not a heckuvalot of data there to play with).  
It's also live at http://www.a2central.com/bugzilla, but that's live data, so 
I'll have to let the people using it play and I'll report back.  Everything's 
still restricted viewing in there.


    
    

    
  
now have a viable patch here... nominating for 2.12 to get it on the radar.  
There's a few other things going on with query.cgi, so this may or may not 
actually go in, depending on the others.  This just gets it on the map so we can 
compare.

Whiteboard: 2.12

    
    

    
  
I believe that the medium query and simple queries should be added also. Simple 
query to index.html with a link to the help info, and the medium query on a 
seperate page.

    
  
Keywords: patch

    
    

    
  
A new patch is on its way... Just a few more hours (I hope)

    
    

    
  

      
      
      
      

        Attached file
          
        new queryhelp.cgi
        — 
      

    


  

    
    

    
  
Per request of a few people, I made the submit button more accessable on 
query.cgi. I also fixed some html errors. On queryhelp.cgi, I moved most of the 
introduction down to the bottom, added 'pictures' of what to do, and added 
spelling fixes, among other things. These last two files are it and should work 
(I hope).

    
    

    
  
*** Bug 41654 has been marked as a duplicate of this bug. ***

    
    

    
  
See also the suggestion andreww@netscape.com made in bug 68741:

I always have to scroll down to submit my queries, and that submit query button 
is hidden between two other big buttons.  We should add another submit query (you 
can have more than one! really!) button at the top to make doing queries faster 
and easier to discover...

Blocks: 68741

    
    

    
  
What I don't like is about this page (and the current one) is that it is
basically upside down.  Things that I usually search on (product, component,
summary, description) are at the bottom and things that I almost never search on
(platform, OS, priority, severity).  I use status and resolution quite a bit so
they should be at the top as they are currently.

    
  
Blocks: 28763
No longer blocks: 68741

    
    

    
  
Stephen: I cannot rearrange the query page based on what a few people want at 
the top. I rearranged the page in order to look attractive and possibly be in a 
slightly better order. Unfortunately, I would never be able to get everyone to 
agree on the best order since I even disagree with you on what should be up 
top. Generally, it follows a logical order.

    
    

    
  

      
      
      
      

        Attached file
          
        The Query Page
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Query Help Page
        — 
      

    


  

    
    

    
  
This is what the final versions look like. The last 4 files are the important 
ones.

    
    

    
  
diff -u for query.cgi is having fits.  Anyway I can get you to regenerate the
diff using -c?

    
    

    
  
Oh never mind.  I twiddle somethings and am getting it to work.  Testing now...

    
    

    
  
Testing reveals that the query.cgi looks great.  Queryhelp.cgi looks stunning in
IE and Mozilla but like absolute crap in Netscape 4.x.

*sigh* *stupid* *pant* *netscape*

Brian, do you think you could find it in yourself to make it a little more
x-browser friendly in the next couple of days?

    
    

    
  
I got it to work in NS6, Mozilla, IE, just got it to work in NS4.x (just now), 
and opera (although it is funky with the colors along with every other page 
that uses bgcolor) and justdave says it works well in iCab. All I have to do is 
fix about a dozen html errors. Fun!

    
    

    
  
Ok, I am pretty sure I've cross-browserized it. I will submit the file in a 
little while. 

So far, I have tested NS6, Opera (has the bgcolor prob), Mozilla, Ns6.01, 
Ns4.x, IE5.x

I also removed every w3c error except what is in the header and footer.

...Hope you like it.

    
    

    
  
BTW, its my birthday :)

    
    

    
  

      
      
      
      

        Attached file
          
        New Queryhelp.cgi
        — 
      

    


  

    
    

    
  
 01/21/01 08:05 diff -u against current cvs 
 01/27/01 12:49 new queryhelp.cgi 
 As of now, this is what you want:

 01/27/01 12:53 diff -u against current cvs 
 02/22/01 05:19 New Queryhelp.cgi 


    
    

    
  
Weirdness... ignore the first two lines. 

Also, I have a question to Dave or Tara (or anyone else): should seperate bugs 
be filed for adding the simple and medium query screens, to Bugzilla? It would 
be really nice if those would be added also (maybe for 2.14), but I think they 
belong in another bug.

    
    

    
  
*** Bug 69952 has been marked as a duplicate of this bug. ***

    
    

    
  
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty

    
    

    
  
moving to real milestones...

Whiteboard: 2.12
Target Milestone: --- → Bugzilla 2.12

    
    

    
  
The blue boxes on the queryhelp.cgi form are messed up at least in NN 4.61.
Maybe putting <form>...</form> around the form element will fix that.

    
    

    
  
Thanks for you're help Andreas. That is what I just fixed. Some people haven't 
updated thier bugzillas yet. To see the newest version, go to 
http://www.netdemonz.com/ and follow the bugzilla links.

    
    

    
  
Okay, latest word on applying this patch.  There are some serious functional
regressions with the new layout code, particularly pertaining to managing
queries that are going to take some thought and I don't want to hold up 2.12 for
it.  Moving out to 2.16 for tracking purposes.  A modified queryhelp.cgi could
still be a good thing for 2.12 however, as it's vastly superior to the old html
help page.
Target Milestone: Bugzilla 2.12 → Bugzilla 2.16

    
    

    
  
Ok, I'm going to post an updated 2.12 queryhelp.cgi. to link to it, all you 
have to do is add the following to the top of query.cgi and remove the clue at 
the bottom since its being moved to the top. The modified queryhelp.cgi will 
give a note that it was written to be in conjunction with the new query.cgi but 
the new query.cgi won't be added until a later version in order to do more 
regression testing.


print qq{
<P>For detailed help on using this query, 
consult <A HREF="queryhelp.cgi">Help Using the Bugzilla Query Form</a> 
</A>. I recommend reading it before trying to find your first bug. You can also
click on any of the headings and some of the subheadings to link to that part 
of the
help document.<br>
<p>
Or... give me a <A HREF=\"help.html\">clue</A> about how to use this form.<br>

};

    
    

    
  
Ignore the invalid images.

    
    

    
  
Checking in queryhelp.cgi since tara checked in a query.cgi two days ago that 
depends on it. :)  I got the version that says this is using a proposed layout 
but the fields are the same.


    
  
Blocks: 71406

    
    

    
  
Please see bug 88788 about making queryhelp.cgi less initimidating.

Please post nothing more in this bug about queryhelp.cgi (pre-emptive strike). 
Make new bugs for it.

I am going to try to revive my patch for query.cgi and remove the problems it 
had. The reason for this is query.cgi doesn't match queryhelp.cgi and also 
query.cgi looks ugly and confusing still.

    
    

    
  
Mass moving to new product Bugzilla...
Assignee: tara → endico
Status: ASSIGNED → NEW
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → 2.13

    
    

    
  
Bug#98123 should provide the user pref functionality to specify a 'default 
query page' for a user, if it is still needed.
Blocks: 98123

    
  
No longer blocks: 98123

    
  
Depends on: 98123

    
    

    
  
If you like this approach you can of course have the underlying cgi code. It 
works for me :)


    
    

    
  
I would add "verified" bugs, since verified != closed, necessarily.  In fact, I
could be mistaken, but perhaps it would be better for bug 13540 purposes if you
changed those radio buttons to a dropdown field, so people can customize the
choices more easily.  After all, some projects using Bugzilla don't necessarily
even use Mozilla's states at all.  For example, AbiSource's Bugzilla uses
"SUBMITTED," "OPEN," and "QA TO VERIFY" (IIRC).

    
    

    
  
Seconded. I've ditched "VERIFIED" for my bugzilla, because I found people
expecting that the be the next step after "UNCONFIRMED", as in "Yes, this is
verified to be a problem". (In fact, I think Red Hat's bugzilla uses "VERIFIED"
to mean exactly that.)

    
    

    
  
I didn't use a dropdown select because it the options are (IMO) much clearer
now. You can immediately see what choices are available.

In light of the 'verified', I don't use milestones, and there are not a lot of
users on my site, so resolved is good enough :) But why make a difference
between verified and resolved? If you want to search for that kind of thing, use
the advanced form. You can't make a simple form without leaving out options.

The point is, you want to show the most common, useful choices, and display them
in a clear way. I think to a lot of users Resolved, Verified and Closed mean the
same thing, that the bug is done with.
(of course, feel free to disagree with me)

I would agree with people saying that it needs javascript to make the components
work though. It's just not useful to me, so I didn't make that work.

    
    

    
  
But there *IS* a difference; RESOLVED means it has been fixed, whereas VERIFIED
means that QA has seen that the bug is fixed, and that it doesn't cause
regressions.  CLOSED is a state which Mozilla hasn't used yet, but which it may
post 1.0.

As to JavaScript: I am totally opposed to seeing JavaScript being used for core
functionality in Bugzilla.  If you are depending on JavaScript for functional
purposes, PLEASE FIX IT.  After all, don't forget that Lynx users like to use
Bugzilla, too.

    
    

    
  
Sure, there's a difference, but as someone mentioned, to most users, they're all
in the general category of "shouldn't be a problem anymore".

    
    

    
  
But I think it is a very important difference for anyone who does QA...  And
they are one of the most important groups using Bugzilla.

However, the reason I suggested the dropdown box is because of bug 13540.  I
think this deserves some consideration too, especially since Bugzilla 3 is
basically going to scrap the current scheme altogether, and be a total re-write
from the ground up.  I don't know where it may go from there.

    
    

    
  
JavaScript is not required anywhere in Bugzilla.  It only enhances user
experiences where possible.  For example, on query.cgi, JavaScript is used to
add and remove possible choices from a drop down list when possible.  Without
JavaScript, there is no good way to prevent a user from selecting the "Bugzilla"
product for example, and "Browser General" component from their respective
dropdowns.  This is the only function the JavaScript does on the site at all. 
We also use it in show_bug to automatically select radio options when you type
something in it's respective field.  We do not depend on JS anywhere and should
not.  As far as I know, the patches included do not use JS at all so I'm not
sure why this is a discussion.

But there is nothing wrong with using JavaScript for enhancing a user
experience.  We *should* use JavaScript here in the same fashion as query.cgi
uses it for the components listing.  The best way to do that would be to share
the JavaScript in separate files between query.cgi and whatever we call the
simplequery page so that if one changes, the other gets the changes as well.

Thus, I am marking a dependency on bug 96983 although this bug COULD be fixed
without 96983 being fixed yet.  I am just setting dependency for relational
purposes.

    
    

    
  
"useful to the QA" is a moot point here.  This is the simple query page, not the
advanced one, that we're talking about.  The QA's can use the advanced form just
like they do now.  No functionality will be removed from the advanced form.
No longer depends on: 96983

    
    

    
  
Seems Dave and I were fighting back and forth to get our comments in and the
dependency got screwed up in a midair.  Re-adding.  Sorry for spam.
Depends on: 96983

    
    

    
  
Hmm...  I guess having a choice for "RESOLVED, VERIFIED, or CLOSED" might work,
if this query implementation is truly targetted mainly at new/simple users. 
However, I suggest that it be labeled as such if this is the case, so it won't
confuse others like me into thinking it ONLY looked for "RESOLVED, BUT NOT
VERIFIED or CLOSED."

I think we should also add a preference to switch between the basic and advanced
query screens if it does get accepted however, so that QA and those kinds of
folks don't have to go through an extra step to get to their preferred screen
all the time.

    
    

    
  
my thinking is that the new simple search should be at a new URL and the old one
can stay where it is.  Just add another link on the front page.

    
    

    
  
OK, now that I'm more awake than I was last night, here's what I would like to
see done with the query page...

We create a new cgi file called search.cgi.  We also create a queryform.pl file
(or .pm file?), which the meat of the current query.cgi gets moved into, and
query.cgi gets replaced with a pass-through that calls queryform.pm.  (similar
to the way show_bug.cgi and process_bug.cgi both call bug_form.pl currently).

For queryform.pm, if the user is not logged in, or hasn't changed their
preferences, it would default to the simple query.  All of the sections of the
query page are broken down into functional components.  Initially, all that
would be shown is the product/component selection and the
summary/description/keyword searches.  There would also be a row of checkboxes
at the top for each of the other sections (email lookup, status/resolution,
os/platform, changes to fields, etc) with a submit button to add one or more of
those sections to the form.

search.cgi would just be a straight passthrough to queryform.pm, with the simple
search by default.

query.cgi would set $::FORM{fullquery}=1 before passing control through, so that
access via that URL would always give you the advanced form, just like it does now.


    
    

    
  
oh, and I forgot to mention, if you always like having a specific set of the
search parameters available on your search page, we can set up preferences for
the users, too, provided they're logged in when they view it.

    
    

    
  
Note that mpt is working on a cleaner and more user-friendly version of query.cgi.

Gerv

    
    

    
  
Gerv: true, but this bug argues for a simplified query.cgi page. I'll update
summary.

- Query confusing for newbies
+ [RFE] optional simplified version of query.cgi
Summary: Query confusing for newbies → [RFE] optional simplified version of query.cgi

    
    

    
  
kiko: if you land the cleaned up, templatised, query.cgi, implementing the
simple query form as another template would be trivial. :-)

Gerv
Depends on: 98707

    
    

    
  
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

    
    

    
  
ok, bug 98707 has landed.  Which completely invalidates almost all of the
patches on this bug.  However, starting over under the new system should be
pretty darn trivial...  all you need is another template, and a way to choose it. :)

Although y'all may want to look at the way the full query page has been
redesigned and see whether this is still necessary or if the redesigned covers
it.  Until bugzilla.mozilla.org picks it up, you can check it out at
http://landfill.tequilarista.org/bugzilla-tip/query.cgi

No longer blocks: 28763

    
    

    
  
Comment on attachment 22234 [details] [diff] [review]
The diff file. (Hope this works)

this is now templatised; so it needs-work

        Attachment #22234 -
        Flags: review-

        Attachment #23097 -
        Attachment is obsolete: true

        Attachment #23097 -
        Flags: review-

        Attachment #23101 -
        Attachment is obsolete: true

        Attachment #23101 -
        Flags: review-

        Attachment #23645 -
        Flags: review-

    
    

    
  
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

    
  
Summary: [RFE] optional simplified version of query.cgi → Optional simplified query interface (query.cgi)

    
  
OS: Linux → All
Hardware: Other → All
Assignee: endico → nobody
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20

    
    

    
  
Cleaning up some ancient stuff and this is now fixed in 2.17.6 with the "Find Specific Bug" feature.

Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
(In reply to comment #106)
> Bug#98123 should provide the user pref functionality to specify a 'default 
> query page' for a user, if it is still needed.

bug 98123 has not yet been addressed, yet this LI has been resolved anyway 
(albeit perhaps only because bug 98707 beat it to the punch).  Dependency is 
irrelevant; removing.
No longer depends on: 98123

    
    

    
  
Fixed by bug 145588.
Assignee: nobody → myk

    
    

    
  
Yep -- I'd say that's exactly what I originally wanted.
Status: RESOLVED → VERIFIED
QA Contact: matty_is_a_geek → default-qa

    
    

    
      
  

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: