From 39cf5154ea35355067791653198b6dbb3fc51ba2 Mon Sep 17 00:00:00 2001 From: "jocuri%softhome.net" <> Date: Sat, 11 Dec 2004 08:27:44 +0000 Subject: Patch for bug 251502: Remove queryhelp.cgi (redundant, badly out of date); patch by me, r=wurblzap (Marc), r=gerv, a=justdave. --- queryhelp.cgi | 1529 --------------------------------------------------------- 1 file changed, 1529 deletions(-) delete mode 100755 queryhelp.cgi (limited to 'queryhelp.cgi') diff --git a/queryhelp.cgi b/queryhelp.cgi deleted file mode 100755 index 361ebc382..000000000 --- a/queryhelp.cgi +++ /dev/null @@ -1,1529 +0,0 @@ -#!/usr/bin/perl -wT -# -*- Mode: perl; indent-tabs-mode: nil -*- -# -# The contents of this file are subject to the Mozilla Public -# License Version 1.1 (the "License"); you may not use this file -# except in compliance with the License. You may obtain a copy of -# the License at http://www.mozilla.org/MPL/ -# -# Software distributed under the License is distributed on an "AS -# IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or -# implied. See the License for the specific language governing -# rights and limitations under the License. -# -# The Original Code is the Bugzilla Bug Tracking System. -# -# The Initial Developer of the Original Code is Netscape Communications -# Corporation. Portions created by Netscape are -# Copyright (C) 1998 Netscape Communications Corporation. All -# Rights Reserved. -# -# Contributor(s): Brian Bober -# Terry Weissman -# Tara Hernandez - -use strict; - -use lib qw(.); - -require "CGI.pl"; - -Bugzilla->login(); - -GetVersionTable(); - -print Bugzilla->cgi->header(); - -PutHeader("Bugzilla Query Page Help","Help", "This page is to help you learn how to use the query form."); - - - - - -print qq{ - -
- -
- - - -

Help Using The Bugzilla Query Form
January, 20 2001 - -Brian Bober (netdemon). -
Further heavy mutiliations by Tara Heranandez, April 20, 2001.
- -
Da Ant
- -


The Sections

- -

The query page is broken down into the following sections: - -

Bug Settings -
People Involved -
Text Search Options -
Module Options -
Advanced Querying -
The Bottom Of The Form - -

"I already know how to use Bugzilla, but would like information about Bugzilla and the author of this document." -
"Ok, I am almost certain the bug I discovered isn't in Bugzilla, how do I submit the bug?" - Read the guidelines first! - -


Tips

-You don't have to fill out any field on the query page you don't need. Filling out fields will limit -your search. On the list boxes, such as Status, you can Ctrl-Click to unselect an option. -Until you get better, you can use the "brute force" method where you enter a very simple query and search through -the long list of bugs manually. Just try not to overuse this method if you don't have to as you might be slowing down -the search for other people if there are many people searching at the same time. Finally, I would recommend learning the Boolean Chart immediately because it is extremely -powerful. Also, there is a navigation bar at the bottom of -most Bugzilla pages, and important links at the front page. - - - -

Back to the Query. If you typed anything in the forms already, you might want to hit back on the -browser. When you are all done reading, do a sample query! - -}; - - - - - -print qq{ - - - -


Bug Settings

- -
- - - - - -
- - - - - - - - - - - - - - - - - -
Status:Resolution:Platform:OpSys:Priority:Severity:
- - - - - - - - - - - - - - - - - -
-
-
- -
- -The status and resolution field define and track the -life cycle of a bug. Platform and opsys describe the system -which the bug is on. Priority and Severity are for tracking purposes. - - -

Status - -

    -
  • UNCONFIRMED - Nobody has validated that this bug needs to be fixed. Users who have the correct -permissions may confirm this bug, changing its state to NEW. You can view -your permissions here. -A bug may be directly resolved and marked RESOLVED but usually a bug will -be confirmed by the person to whom it is assigned. Usually, an UNCOMFIRMED bug -will be left uncomfirmed until someone has verified that the bug the reporter -submitted actually occurrs. - -
  • NEW - This bug has recently been added to the assignee's list of bugs -and must be processed. Bugs in this state may be accepted, and -become ASSIGNED, passed on to someone else, and remain -NEW, or resolved and marked RESOLVED. - -
  • ASSIGNED - This bug is not yet resolved, but is assigned to someone who -thinks they can fix it. From here bugs can be given to another person and become -NEW, or resolved and become RESOLVED. - -
  • REOPENED - The bug was once resolved, but the resolution was deemed -incorrect. For example, a WORKSFORME bug is -REOPENED when more information shows up and the bug is now -reproducible. From here bugs are either marked ASSIGNED -or RESOLVED. - -
  • RESOLVED - A resolution has been made, and it is awaiting verification by -the QA. From here bugs are either re-opened and become REOPENED, are marked -VERIFIED, or are closed for good and marked CLOSED. - -
  • VERIFIED- QA has looked at the bug and the resolution and agrees that the -appropriate action has been taken. - -
  • CLOSED - The bug is considered dead, the resolution is correct, and the product the bug -has been reported against is terminated or shipped. Any zombie -bugs who choose to walk the earth again must do so by becoming -REOPENED. This state is rarely ever used. -
- - -

Resolution - -

The resolution field indicates what happened to this bug. - -

No resolution yet: All bugs which are in one of the "open" states (meaning the state -has no associated resolution) -have the resolution set to blank. All other bugs -will be marked with one of the following resolutions. - -

    -
  • FIXED - A fix for this bug is checked into the tree and tested. -
  • INVALID - The problem described is not a bug. -
  • WONTFIX - The problem described is a bug which will never be fixed. -
  • LATER - The problem described is a bug which will not be fixed in this -version of the product. -
  • REMIND - The problem described is a bug which will probably not be fixed in this -version of the product, but might still be. -
  • DUPLICATE - The problem is a duplicate of an existing bug. Marking a bug -duplicate requires the bug number of the duplicate and that number will be placed in the -bug description. -
  • WORKSFORME - All attempts at reproducing this bug were futile, reading the -code produces no clues as to why this behavior would occur. If -more information appears later, please re-assign the bug, for -now, file it. -}; - -print '
  • MOVED - The problem described might be a bug but is not a bug in this database, -so it was transfered to a more appropriate database.' - if Param('move-enabled'); - -print qq{ -
- - -

Platform -

The platform field is the hardware platform against which the bug was reported. Legal -platforms include but are not limited to: - -

    -
  • All (happens on all platform; cross-platform bug)
    -
  • Macintosh -
  • PC -
  • Sun -
  • HP -
-

Note: Selecting the option "All" does not select bugs assigned against all platforms. It -merely selects bugs that occur on all platforms. - - -

Operating System -

The operating system field is the operating system against which the bug was reported. Legal -operating systems include but are not limited to: - -

    -
  • All (happens on all operating systems; cross-platform bug) -
  • Windows 95 -
  • Windows 2000 -
  • Mac System 8.0 -
  • Linux -
  • Other (Not in any of these OSes)
    -
- -

Note that the operating system implies the platform, but not always. -For example, Linux can run on PC and Macintosh and others. - - -

Priority - -

The priority field describes the importance and order in which a bug should be -fixed. This field is utilized by the programmers/engineers to -prioritize their work. The priorities are from P1 (Most important) to P5 -(Least important). - - -

Severity - -

The Severity field describes the impact of a bug. - -

    -
  • Blocker - Blocks development and/or testing work.
    -
  • Critical - Crashes, loss of data, severe memory leak.
    -
  • Major - Major loss of function.
    -
  • Normal - This is the run of the mill bug.
    -
  • Minor - Minor loss of function, or other problem where an easy workaround is present.
    -
  • Trivial - Cosmetic problem like misspelled words or misaligned text.
    -
  • Enhancement - Request for enhancement.
    -
- -}; - - - - - - - - - - - - -print qq{ - -


People Involved

-
- - - - - - -
- - - - - - - - - - - - - - -
Email: - matching as:
- -
Will match any of the following selected fields:
-
-Assigned To -Reporter - -QA Contact -
-
-CC -Added comment -
- -
-
-
- -This section has been made more complicated in order to make it more powerful. Unfortunately, -it is not the easiest to understand. What this section lets you do is search for bugs associated -with a certain email address. - -

- -To search for bugs associated with an email address: - -

    -
  • Type a portion of an email address into the text field. -
  • Click the checkbox for the fields of the bug you expect the address will be within. -
- -

- -You can look for up to two different email addresses. If you specify -both, then only bugs which match both emails will show up. This is useful to -find bugs that were, for example, created by Ralph and assigned to -Fred. - -

- -You can also use the drop down menus to specify whether you want to -match addresses by doing a substring match, by using Regular -Expressions, or by exactly matching a fully specified email address. - - -}; - - - - - - - - - - - -print qq{ - -


Text Search

-
- - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bug summary:
A description entry:
Associated URL:
Status whiteboard:
Keywords: -
-
-
-
- - -

In this section, you can enter values that are searched for in all the bugs (or whatever you -limit the bugs to in other fields). -You might want to look at Bugzilla Text Searching -to see info on Regular Expressions and text searching. The box next to these fields decides -how a match will be determined.
- - -

Bug summary

-

This lets you search the summaries. The summary is one line that attempts to sum up the bug. - - -

A description entry

-

This lets you search comments. Comments can be added by anybody. Comments are the largest -searchable area in most bugs. If you really want to find a lot of matches, search the comments. -
Note:Because comments can get quite extensive in bugs, doing this particular type -of query can take a long time. - - -

Associated URL

-

This lets you search the url field. This contains the url of the web page the bug is -about. - - -

Status Whiteboard

-

This lets you search the bug's status whiteboard. The status whiteboard contains general -information that engineers add. -}; - - -print qq{ - -

Keywords

-

Each bug can have keywords specified. The bug reporter or a -user with the proper permissions can edit these keywords. The following is a list of the keywords that are -stored on this version of Bugzilla: -}; - -my $tableheader = qq{ -

- - - - - -}; - -print $tableheader; - -my $line_count = 0; -my $max_table_size = 50; - -SendSQL("SELECT keyworddefs.name, keyworddefs.description, - COUNT(keywords.bug_id) - FROM keyworddefs LEFT JOIN keywords ON keyworddefs.id=keywords.keywordid - GROUP BY keyworddefs.id - ORDER BY keyworddefs.name"); - -while (MoreSQLData()) { - my ($name, $description, $bugs) = FetchSQLData(); - if ($bugs) { - my $q = url_quote($name); - $bugs = qq{$bugs}; - } else { - $bugs = "none"; - } - if ($line_count == $max_table_size) { - print "
NameDescriptionBugs
\n$tableheader"; - $line_count = 0; - } - $line_count++; - print qq{ - -$name -$description -$bugs - -}; -} - -print "

\n"; - - -if (UserInGroup("editkeywords")) { - print qq{

Edit keywords\n}; -} - - - - - - - - - - - - -my %default; -my %type; - -print qq{ - -


Module Options

- -
- -

Module options are where you select what product, module and version the bugs you want to -find describe. Selecting one or more of the products, versions, components, or milestones will limit your search. - -

-

Products

- - -

Although all subprojects within the Mozilla project are similar, there are several seperate -products being developed. Each product has its own components. - -}; - - - - -$line_count = 0; -$max_table_size = 50; -my @products; -my $product; - -$tableheader = qq{

}; - - -} - - -print qq{ - -
- - - - }; - - -print qq{ - $tableheader -}; - - -SendSQL("SELECT name, description FROM products ORDER BY name"); - while (MoreSQLData()) { - - my ($product, $productdesc) = FetchSQLData(); - next if (!CanEnterProduct($product)); - push (@products, $product); - - $line_count++; - if ($line_count > $max_table_size) { - print qq{ -
ProductDescription
- $tableheader - }; - $line_count=1; - } - - print qq{
$product$productdesc
}; - -if (UserInGroup("editcomponents")) { - print qq{

Edit products

}; -} - -print qq{ -

-

Version

- -

This is simply the version that the bugs you want to find are marked for. -Many of the bugs will be marked for another version and will have their milestones -entered instead (milestones explained below). - -}; - - - - - -$line_count = 0; -$tableheader = qq{ -

- - - - - -}; - -print qq{ -

-

Component

-

Each product has components, against which bugs can be filed. Components are parts of -the product, and are assigned to a module owner. The following lists -components and their associated products: - $tableheader -}; -foreach $product (@products) -{ - - SendSQL("SELECT components.name, components.description " . - "FROM components, products " . - "WHERE components.product_id = products.id" . - " AND products.name = " . SqlQuote($product) . - "ORDER BY name"); - - while (MoreSQLData()) { - - my ($component, $compdesc) = FetchSQLData(); - - $line_count++; - if ($line_count > $max_table_size) { - print qq{ -

ComponentProductDescription
- $tableheader - }; - $line_count=0; - } - print qq{$component$product$compdesc}; - } - -} - -print qq{}; -if (UserInGroup("editcomponents")) { - print qq{

Edit components

}; -} - -print qq{ -

-

Milestone

- -

Choosing this section lets you search through bugs that have their target milestones set to certain -values. Milestones are kind of like versions. They are specific tentative dates where a massive -phasing out of bugs occur and a relatively stable release is produced. For example, Mozilla.org had milestones in the -form of "M10" or "M18", but now are in the form of "Mozilla0.9". Bugzilla milestones are in the form of "Bugzilla 2.12", -"Bugzilla 2.14", etc. - - -}; - - - - - - - - - - - - - - -print qq{ - -


Inclusion/Exclusion Options

- -
- - - - - - -
- - - - - - - - - - - - - - - - - - - - - - -
- -bugs numbered: - -
 
-Only bugs changed between -and -
-Where one or more of the following changed: - - -
-and the result was: -
 
-Containing at least votes -
- -
- -
- -
-
- -

Inclusion/Exclusion options is a powerful section that gives you the ability to include and -exclude bugs based on values you enter. - -

[Only, Exclude] bugs numbered [text] - -

This lets you put in a comma-delimited list of bugs you want to have your results chosen from, or those -of which you want to exclude. It would be nice in the future if you could type in ranges, i.e. [1-1000] for 1 -to 1000. Unfortunately, you cannot do that as of now. - -

At least [text] votes - -

With this, you can choose how many votes - at minimum - a bug has. - - -

Only bugs changed between

- -

Here you can choose what dates the bugs changed. "Now" can be used as an -entry. Other entries should be in yyyy-mm-dd format, or in relative dates such -as 1d or 2w or 3m or 4y, which respectively mean 1 day, 2 weeks, 3 months, 4 -years ago. 0d is last midnight, and 0w, 0m, 0y is the beginning of this week, -month, or year.

- -

Where one or more of the following changed, and the result was

- -

With this you can specify which bug fields changed, and optionally to what -value, between the dates specified above. Leaving blank will match any change.

- - -}; - - - - - - - - - - - - -print qq{ - -


Advanced Querying Using "Boolean Charts"

- -

The Bugzilla query page is designed to be reasonably easy to use. -But, with such ease of use always comes some lack of power. The -Advanced Querying section is designed to let you do very powerful -queries, but it's not the easiest thing to learn (or explain). -
-

-

- - - - - -
- - -
- - - -
 
  -       - - - -
-
-
- -
-
-

The Advanced Query (or Boolean Chart) starts with a single "term". A term is a -combination of two pulldown menus and a text field. -You choose items from the menus, specifying: -

Field 1: Where to look for the search term
-Field 2: How to determine what is a match
-Field 3: What the search term is
-
-

- - - - - -
- - -
- - - -
 
OR
  -       - - - -
-
-
- -
- -
-

The real fun starts when you click on the "Or" or "And" buttons. If -you push the "Or" button, then you get a second term right under -the first one. You can then configure that term, and the result of -the query will be anything that matches either of the terms. -
-

-

- - - - - -
- - - -
- - - - -
 
 AND
 
  -       - - - -
-
-
- -
-
-

You can push the "And" button, and get a new term below the -original one - seperated by the word "AND", and now the result of -the query will be anything that matches both sets of terms. - -

You can keep clicking "And" and "Or", and get a page with many -terms. "Or" has higher precedence than "And". You -can think of the lines of "Or" as having parenthesis around them. - -

-

- - - - - -
- - - -
- - - - - - - -
 
  -
  -       - - - -
-
-
- - -
-
-

The most subtle thing to notice is the "Add another boolean chart" button. -This is almost the same thing as the "And" button. You want to use this when -you use one of the fields where several items can be associated -with a single bug - including: "Comments", "CC", and all the -"changed [something]" entries. If you have multiple terms that -all are about one of these fields (such as one comment), it's ambiguous whether they are -allowed to be about different instances of that field or about only that one instance. So, -to let you have it both ways, they always mean the same instance, -unless the terms appear on different charts. - -

For example: if you search for "priority changed to P5" and -"priority changed by person\@addr", it will only find bugs where the -given person at some time changed the priority to P5. However, if -what you really want is to find all bugs where the milestone was -changed at some time by the person, and someone (possibly someone -else) at some time changed the milestone to P5, then you would put -the two terms in two different charts. -}; - - -print qq{ - -

The Rest of the Form

-
- - - - - - -
- - - - -
- Load the remembered query: -
- Run the remembered query:
- Forget the remembered query:
- Remember this as the default query
- Remember this query, and name it: -
-Sort By: - -
- - - - - -
- - - -
-
- - - -
-
-

So you have gotten all that down, but "What is this junk at the bottom of the form?" -You can remember the current query as the default query page that is pulled up whenever you are -logged on. There is also an ability to choose how you want your results sorted. When finished, -click "Submit". -}; - - - - -print qq{ - - - -

About This Document

- -

Written and adapted from some older Bugzilla documents (by Terry Weissman, Tara Hernandez and others) by Brian Bober -You can talk to me on irc.mozilla.org - #mozilla, #mozwebtools, #mozillazine, I go by the name netdemon. - -

Lots of Bugzilla use documention is available through Mozilla.org and other sites: -
-How To Find Previously Reported Bugs
-Bugzilla General Information
-Mozilla Bug Report Form
-Bugzilla Text Searching
-The Bug Reporting Guidelines
-

My main motive for writing this was to help the engineers by giving new Bugzilla users a way to learn how to use the Bugzilla Query form. I -had done a rewrite of query.cgi, so I said, "What the heck, I'll write this too". - -


Why Use This?

- -

You probably looked at the Query page and said, "This page looks too difficult. Now that -I think about it, I don't really need to do a query". It is important to make sure that a bug -doesn't have a duplicate before submitting it, as is stated clearly in -The Bug Reporting Guidelines. -The people reading your bugs are busy and usually swamped with bugs. Therefore, you are doing everyone -a huge favor to search for a duplicate. - - - -}; - - - - - - - - -print qq{ - -


Sample Query

- -

Ok. So lets find a bug! We'll borrow the Mozilla.org database because it's handy. -
First, lets make a -copy of the query window so you can easily switch between this document and the query. -

Do the following: -

    -
  • Go to the "Status" field in and select all fields (or deselect all fields). -
  • In Text Search options, put Autoscroll in the summary and Panning in the description entry box -(meaning that panning is somewhere in the comments and the bug's summary has Autoscroll in it). -
-

One of the results should have been bug 22775 - [RFE] AutoScroll/Panning support... -}; - -print qq{ -

- - - -
- -}; - - - -PutFooter(); -- cgit v1.2.3-24-g4f1b