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..

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 .)

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.

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.

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.

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.

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.

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.

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

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...

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.

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.

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 :)

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.

moving to real milestones...

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.

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.

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...

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

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.

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.

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

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

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.

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

Comment on attachment 22234 [details] [diff] [review] The diff file. (Hope this works) this is now templatised; so it needs-work

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

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

(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.

Fixed by bug 145588.

Yep -- I'd say that's exactly what I originally wanted.