<listitem>
<para>
- <emphasis>Disable Text</emphasis>:
- If you type anything in this box, including just a space, the
- user is prevented from logging in, or making any changes to
- bugs via the web interface.
- The HTML you type in this box is presented to the user when
- they attempt to perform these actions, and should explain
- why the account was disabled.
- <warning>
- <para>Don't disable all the administrator accounts!</para>
- </warning>
-
+ <emphasis>Disable Text</emphasis>:
+ If you type anything in this box, including just a space, the
+ user is prevented from logging in, or making any changes to
+ bugs via the web interface.
+ The HTML you type in this box is presented to the user when
+ they attempt to perform these actions, and should explain
+ why the account was disabled.
+ </para>
+ <para>
+ Users with disabled accounts will continue to receive
+ mail from Bugzilla; furthermore, they will not be able
+ to log in themselves to change their own preferences and
+ stop it. If you want an account (disabled or active) to
+ stop receiving mail, add the account name (one account
+ per line) to the file <filename>data/nomail</filename>.
+ </para>
<note>
- <para>The user can still submit bugs via
- the e-mail gateway, if you set it up, even if the disabled text
- field is filled in. The e-mail gateway should
- <emphasis>not</emphasis>
- be enabled for secure installations of Bugzilla.</para>
+ <para>
+ Even users whose accounts have been disabled can still
+ submit bugs via the e-mail gateway, if one exists.
+ The e-mail gateway should <emphasis>not</emphasis> be
+ enabled for secure installations of Bugzilla.
+ </para>
</note>
- </para>
+ <warning>
+ <para>
+ Don't disable all the administrator accounts!
+ </para>
+ </warning>
</listitem>
<listitem>
<listitem>
<para>
If the manager thinks the feature should go into the product
- before version 2.0 can be released, he sets the flag to
- <quote>+</quote>. Otherwise, he sets it to <quote>-</quote>.
+ before version 2.0 can be released, he sets the flag to
+ <quote>+</quote>. Otherwise, he sets it to <quote>-</quote>.
</para>
</listitem>
<listitem>
<varlistentry>
<term><computeroutput>-</computeroutput></term>
<listitem><simpara>
- The status has been set negatively. (The question has been answered <quote>no</quote>.)
+ The status has been set negatively. (The question has been answered <quote>no</quote>.)
</simpara></listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>+</computeroutput></term>
<listitem><simpara>
- The status has been set positively. (The question has been answered <quote>yes</quote>.)
- </simpara></listitem>
+ The status has been set positively.
+ (The question has been answered <quote>yes</quote>.)
+ </simpara></listitem>
</varlistentry>
</variablelist>
</para>
Actually, there's a fourth value a flag can have --
<quote>unset</quote> -- which shows up as a blank space. This
just means that nobody has expressed an opinion (or asked
- someone else to express an opinion) about this bug or attachment.
+ someone else to express an opinion) about this bug or attachment.
</para>
</section>
</section>
<para>
This describes the flag in more detail. At present, this doesn't
whos up anywhere helpful; ideally, it would be nice to have
- it show up as a tooltip. This field
+ it show up as a tooltip. This field
can be as long as you like, and can contain any character you want.
</para>
</section>
<para>
Default behaviour for a newly-created flag is to appear on
- products and all components, which is why <quote>__Any__:__Any__</quote>
- is already entered in the <quote>Inclusions</quote> box.
- If this is not your desired behaviour, you must either set some
- exclusions (for products on which you don't want the flag to appear),
- or you must remove <quote>__Any__:__Any__</quote> from the Inclusions box
- and define products/components specifically for this flag.
+ products and all components, which is why <quote>__Any__:__Any__</quote>
+ is already entered in the <quote>Inclusions</quote> box.
+ If this is not your desired behaviour, you must either set some
+ exclusions (for products on which you don't want the flag to appear),
+ or you must remove <quote>__Any__:__Any__</quote> from the Inclusions box
+ and define products/components specifically for this flag.
</para>
<para>
To create an Inclusion, select a Product from the top drop-down box.
- You may also select a specific component from the bottom drop-down box.
- (Setting <quote>__Any__</quote> for Product translates to,
- <quote>all the products in this Bugzilla</quote>.
- Selecting <quote>__Any__</quote> in the Component field means
+ You may also select a specific component from the bottom drop-down box.
+ (Setting <quote>__Any__</quote> for Product translates to,
+ <quote>all the products in this Bugzilla</quote>.
+ Selecting <quote>__Any__</quote> in the Component field means
<quote>all components in the selected product.</quote>)
- Selections made, press <quote>Include</quote>, and your
- Product/Component pairing will show up in the <quote>Inclusions</quote> box on the right.
- </para>
+ Selections made, press <quote>Include</quote>, and your
+ Product/Component pairing will show up in the <quote>Inclusions</quote> box on the right.
+ </para>
<para>
To create an Exclusion, the process is the same; select a Product from the
- top drop-down box, select a specific component if you want one, and press
- <quote>Exclude</quote>. The Product/Component pairing will show up in the
- <quote>Exclusions</quote> box on the right.
- </para>
+ top drop-down box, select a specific component if you want one, and press
+ <quote>Exclude</quote>. The Product/Component pairing will show up in the
+ <quote>Exclusions</quote> box on the right.
+ </para>
<para>
- This flag <emphasis>will</emphasis> and <emphasis>can</emphasis> be set for any
- products/components that appearing in the <quote>Inclusions</quote> box
- (or which fall under the appropriate <quote>__Any__</quote>).
- This flag <emphasis>will not</emphasis> appear (and therefore cannot be set) on
- any products appearing in the <quote>Exclusions</quote> box.
- <emphasis> IMPORTANT: Exclusions override inclusions.</emphasis>
+ This flag <emphasis>will</emphasis> and <emphasis>can</emphasis> be set for any
+ products/components that appearing in the <quote>Inclusions</quote> box
+ (or which fall under the appropriate <quote>__Any__</quote>).
+ This flag <emphasis>will not</emphasis> appear (and therefore cannot be set) on
+ any products appearing in the <quote>Exclusions</quote> box.
+ <emphasis> IMPORTANT: Exclusions override inclusions.</emphasis>
</para>
- <para>
- You may select a Product without selecting a specific Component,
- but it is illegal to select a Component without a Product, or to select a
- Component that does not belong to the named Product. Doing so as of
- this writing (2.18rc3) will raise an error... even if all your products
- have a component by that name.
+ You may select a Product without selecting a specific Component,
+ but it is illegal to select a Component without a Product, or to select a
+ Component that does not belong to the named Product. Doing so as of
+ this writing (2.18rc3) will raise an error... even if all your products
+ have a component by that name.
</para>
<para><emphasis>Example:</emphasis> Let's say you have a product called
<quote>Jet Plane</quote> that has thousands of components. You want
- to be able to ask if a problem should be fixed in the next model of
- plane you release. We'll call the flag <quote>fixInNext</quote>.
- But, there's one component in <quote>Jet Plane,</quote>
- called <quote>Pilot.</quote> It doesn't make sense to release a
- new pilot, so you don't want to have the flag show up in that component.
- So, you include <quote>Jet Plane:__Any__</quote> and you exclude
- <quote>Jet Plane:Pilot</quote>.
+ to be able to ask if a problem should be fixed in the next model of
+ plane you release. We'll call the flag <quote>fixInNext</quote>.
+ But, there's one component in <quote>Jet Plane,</quote>
+ called <quote>Pilot.</quote> It doesn't make sense to release a
+ new pilot, so you don't want to have the flag show up in that component.
+ So, you include <quote>Jet Plane:__Any__</quote> and you exclude
+ <quote>Jet Plane:Pilot</quote>.
</para>
</section>
Bugzilla database, but stop users from setting any new flags of this type.
To do this, uncheck <quote>active</quote>. Deactivated
flags will still show up in the UI if they are ?, +, or -, but they
- may only be cleared (unset), and cannot be changed to a new value.
+ may only be cleared (unset), and cannot be changed to a new value.
Once a deactivated flag is cleared, it will completely disappear from a
bug/attachment, and cannot be set again.
</para>
</section>
- <section id="flags-create-field-requestable">
- <title>Requestable</title>
- <para>
- New flags are, by default, <quote>requestable</quote>, meaning that they
- offer users the <quote>?</quote> option, as well as <quote>+</quote> and <quote>-</quote>.
- To remove the ? option, uncheck <quote>requestable</quote>.
- </para>
- </section>
-
- <section id="flags-create-field-cclist">
- <title>CC List</title>
-
- <para>
- If you want certain users to be notified every time this flag is
- set to ?, -, +, or unset, add them here. This is a comma-separated
- list of email addresses that need not be restricted to Bugzilla usernames..
- </para>
- </section>
-
- <section id="flags-create-field-specific">
- <title>Specifically Requestable</title>
- <para>
- By default this box is checked for new flags, meaning that users may make
- flag requests of specific individuals. Unchecking this box will remove the
- text box next to a flag; if it is still requestable, then requests may
- only be made <quote>to the wind.</quote> Removing this after specific
- requests have been made will not remove those requests; that data will
- stay in the database (though it will no longer appear to the user).
- </para>
- </section>
-
- <section id="flags-create-field-multiplicable">
- <title>Multiplicable</title>
- <para>
- Any flag with <quote>Multiplicable</quote> set (default for new flags is 'on')
- may be set more than once. After being set once, an unset flag
- of the same type will appear below it with <quote>addl.</quote> (short for
- <quote>additional</quote>) before the name. There is no limit to the number of
- times a Multiplicable flags may be set on the same bug/attachment.
- </para>
- </section>
-
- </section> <!-- flags-create -->
-
- <section id="flags-delete">
- <title>Deleting a Flag</title>
+ <section id="flags-create-field-requestable">
+ <title>Requestable</title>
+ <para>
+ New flags are, by default, <quote>requestable</quote>, meaning that they
+ offer users the <quote>?</quote> option, as well as <quote>+</quote>
+ and <quote>-</quote>.
+ To remove the ? option, uncheck <quote>requestable</quote>.
+ </para>
+ </section>
- <para>
- When you are at the <quote>Administer Flag Types</quote> screen,
- you will be presented with a list of Bug flags and a list of Attachment
- Flags.
- </para>
- <para>
- To delete a flag, click on the <quote>Delete</quote> link next to
- the flag description.
- </para>
- <warning>
- <para>
- Once you delete a flag, it is <emphasis>gone</emphasis> from
- your Bugzilla. All the data for that flag will be deleted.
- Everywhere that flag was set, it will disappear,
- and you cannot get that data back. If you want to keep flag data,
- but don't want anybody to set any new flags or change current flags,
- unset <quote>active</quote> in the flag Edit form.
- </para>
- </warning>
- </section>
+ <section id="flags-create-field-cclist">
+ <title>CC List</title>
- <section id="flags-edit">
- <title>Editing a Flag</title>
- <para>
- To edit a flag's properties, just click on the <quote>Edit</quote>
- link next to the flag's description. That will take you to the same
- form described in the <quote>Creating a Flag</quote> section.
- </para>
- </section>
+ <para>
+ If you want certain users to be notified every time this flag is
+ set to ?, -, +, or unset, add them here. This is a comma-separated
+ list of email addresses that need not be restricted to Bugzilla usernames..
+ </para>
+ </section>
+
+ <section id="flags-create-field-specific">
+ <title>Specifically Requestable</title>
+ <para>
+ By default this box is checked for new flags, meaning that users may make
+ flag requests of specific individuals. Unchecking this box will remove the
+ text box next to a flag; if it is still requestable, then requests may
+ only be made <quote>to the wind.</quote> Removing this after specific
+ requests have been made will not remove those requests; that data will
+ stay in the database (though it will no longer appear to the user).
+ </para>
+ </section>
+
+ <section id="flags-create-field-multiplicable">
+ <title>Multiplicable</title>
+ <para>
+ Any flag with <quote>Multiplicable</quote> set (default for new flags is 'on')
+ may be set more than once. After being set once, an unset flag
+ of the same type will appear below it with <quote>addl.</quote> (short for
+ <quote>additional</quote>) before the name. There is no limit to the number of
+ times a Multiplicable flags may be set on the same bug/attachment.
+ </para>
+ </section>
+
+ </section> <!-- flags-create -->
+
+ <section id="flags-delete">
+ <title>Deleting a Flag</title>
+
+ <para>
+ When you are at the <quote>Administer Flag Types</quote> screen,
+ you will be presented with a list of Bug flags and a list of Attachment
+ Flags.
+ </para>
+ <para>
+ To delete a flag, click on the <quote>Delete</quote> link next to
+ the flag description.
+ </para>
+ <warning>
+ <para>
+ Once you delete a flag, it is <emphasis>gone</emphasis> from
+ your Bugzilla. All the data for that flag will be deleted.
+ Everywhere that flag was set, it will disappear,
+ and you cannot get that data back. If you want to keep flag data,
+ but don't want anybody to set any new flags or change current flags,
+ unset <quote>active</quote> in the flag Edit form.
+ </para>
+ </warning>
+ </section>
+
+ <section id="flags-edit">
+ <title>Editing a Flag</title>
+ <para>
+ To edit a flag's properties, just click on the <quote>Edit</quote>
+ link next to the flag's description. That will take you to the same
+ form described in the <quote>Creating a Flag</quote> section.
+ </para>
+ </section>
- </section> <!-- flags-admin -->
+ </section> <!-- flags-admin -->
- <!-- XXX We should add a "Uses of Flags" section, here, with examples. -->
+ <!-- XXX We should add a "Uses of Flags" section, here, with examples. -->
- </section> <!-- flags -->
+ </section> <!-- flags -->
<section id="voting">
<title>Voting</title>
<listitem>
<para>
<emphasis>Attachments:</emphasis>
- You can attach files (e.g. testcases or patches) to bugs. If there
- are any attachments, they are listed in this section. Attachments are
- normally stored in the Bugzilla database, unless they are marked as
- Big Files, which are stored directly on disk and (unlike attachments
- kept in the database) may be deleted at some future time.
- </para>
+ You can attach files (e.g. testcases or patches) to bugs. If there
+ are any attachments, they are listed in this section.</para>
</listitem>
<listitem>
</orderedlist>
</section>
- <section id="lifecycle">
- <title>Life Cycle of a Bug</title>
-
- <para>
- The life cycle, also known as work flow, of a bug is currently hardcoded
- into Bugzilla. <xref linkend="lifecycle-image"/> contains a graphical
- repsentation of this life cycle. If you wish to customize this image for
- your site, the <ulink url="../images/bzLifecycle.xml">diagram file</ulink>
- is available in <ulink url="http://www.gnome.org/projects/dia">Dia's</ulink>
- native XML format.
- </para>
-
- <figure id="lifecycle-image">
- <title>Lifecycle of a Bugzilla Bug</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="../images/bzLifecycle.png" scale="66" />
- </imageobject>
- </mediaobject>
- </figure>
- </section>
-
<section id="query">
<title>Searching for Bugs</title>
<para>Once you've run a search, you can save it as a Saved Search, which
appears in the page footer.</para>
- <section id="boolean">
- <title>Boolean Charts</title>
- <para>
- Highly advanced querying is done using Boolean Charts.
- </para>
- <para>
- The boolean charts further restrict the set of results
- returned by a query. It is possible to search for bugs
- based on elaborate combinations of critera.
- </para>
- <para>
- The simplest boolean searches have only one term. These searches
- permit the selected left <emphasis>field</emphasis>
- to be compared using a
- selectable <emphasis>operator</emphasis> to a
- specified <emphasis>value.</emphasis>
- Using the "And," "Or," and "Add Another Boolean Chart" buttons,
- additonal terms can be included in the query, further
- altering the list of bugs returned by the query.
- </para>
- <para>
- There are three fields in each row of a boolean search.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>Field:</emphasis>
- the items being searched
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>Operator:</emphasis>
- the comparison operator
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>Value:</emphasis>
- the value to which the field is being compared
- </para>
- </listitem>
- </itemizedlist>
- <section id="pronouns">
- <title>Pronoun Substitution</title>
- <para>
- Sometimes, a query needs to compare a field containing
- a user's ID (such as ReportedBy) with
- a user's ID (such as the user running the query or the user
- to whom each bug is assigned). When the operator is either
- "equals" or "notequals", the value can be "%reporter%",
- "%assignee%", "%qacontact%", or "%user%." The user pronoun
- referes to the user who is executing the query or, in the case
- of whining reports, the user who will be the recipient
- of the report. The reporter, assignee, and qacontact
- pronouns refer to the corresponding fields in the bug.
- </para>
- </section>
- <section id="negation">
- <title>Negation</title>
- <para>
- At first glance, negation seems redundant. Rather than
- searching for
- <blockquote>
- <para>
- NOT("summary" "contains the string" "foo"),
- </para>
- </blockquote>
- one could search for
- <blockquote>
- <para>
- ("summary" "does not contain the string" "foo").
- </para>
- </blockquote>
- However, the search
- <blockquote>
- <para>
- ("CC" "does not contain the string" "@mozilla.org")
- </para>
- </blockquote>
- would find every bug where anyone on the CC list did not contain
- "@mozilla.org" while
- <blockquote>
- <para>
- NOT("CC" "contains the string" "@mozilla.org")
- </para>
- </blockquote>
- would find every bug where there was nobody on the CC list who
- did contain the string. Similarly, the use of negation also permits
- complex expressions to be built using terms OR'd together and then
- negated. Negation permits queries such as
- <blockquote>
- <para>
- NOT(("product" "equals" "update") OR
- ("component" "equals" "Documentation"))
- </para>
- </blockquote>
- to find bugs that are neither
- in the update product or in the documentation component or
- <blockquote>
- <para>
- NOT(("commenter" "equals" "%assignee%") OR
- ("component" "equals" "Documentation"))
- </para>
- </blockquote>
- to find non-documentation
- bugs on which the assignee has never commented.
- </para>
- </section>
- <section id="multiplecharts">
- <title>Multiple Charts</title>
- <para>
- The terms within a single row of a boolean chart are all
- constraints on a single piece of data. If you are looking for
- a bug that has two different people cc'd on it, then you need
- to use two boolean charts. A search for
- <blockquote>
- <para>
- ("cc" "contains the string" "foo@") AND
- ("cc" "contains the string" "@mozilla.org")
- </para>
- </blockquote>
- would return only bugs with "foo@mozilla.org" on the cc list.
- If you wanted bugs where there is someone on the cc list
- containing "foo@" and someone else containing "@mozilla.org",
- then you would need two boolean charts.
- <blockquote>
- <para>
- First chart: ("cc" "contains the string" "foo@")
- </para>
- <para>
- Second chart: ("cc" "contains the string" "@mozilla.org")
- </para>
- </blockquote>
- The bugs listed will be only the bugs where ALL the charts are true.
- </para>
- </section>
- </section>
+ <para>Highly advanced querying is done using Boolean Charts. See the
+ Boolean Charts help link on the Search page for more information.</para>
</section>
<section id="list">
get the buglist as comma-separated values, for import into e.g.
a spreadsheet.</member>
-
- <member>
- <emphasis>RSS</emphasis>
-
- get the buglist as an RSS 1.0 feed. Copy this link into your
- favorite feed reader. If you are using Firefox, you can also
- save the list as a live bookmark by clicking the live bookmark
- icon in the status bar. To limit the number of bugs in the feed,
- add a limit=n parameter to the URL.</member>
-
- <member>
- <emphasis>iCalendar</emphasis>
-
- Get the buglist as an iCalendar file. Each bug is represented as a
- to-do item in the imported calendar.</member>
-
+
<member>
<emphasis>Change Columns:</emphasis>
If your account is sufficiently empowered, you can make the same
change to all the bugs in the list - for example, changing their
- assignee.</member>
+ owner.</member>
<member>
- <emphasis>Send mail to bug assignees:</emphasis>
+ <emphasis>Send mail to bug owners:</emphasis>
- Sends mail to the assignees of all bugs on the list.</member>
+ Sends mail to the owners of all bugs on the list.</member>
<member>
<emphasis>Edit Search:</emphasis>
</member>
</simplelist>
</para>
-
- <para>
- If you would like to access the bug list from another program
- it is often useful to have the list returned in something other
- than HTML. By adding the ctype=type parameter into the bug list URL
- you can specify several alternate formats. The supported formats
- are: Comma Separated Values (ctype=csv), iCalendar (ctype=ics),
- RDF Site Summary (RSS) 1.0 (ctype=rss), ECMAScript, also known
- as JavaScript (ctype=js), and finally Resource Description Framework
- RDF/XML (ctype=rdf).
- </para>
</section>
<section id="bugreports">
Content-Type (e.g. application/xhtml+xml), you can override this
using a 'content-type' parameter on the URL, e.g.
<filename>&content-type=text/plain</filename>.
- </para>
-
- <para>
- If you have a really large attachment, something that does not need to
- be recorded forever (as most attachments are), you can mark your
- attachment as a Big File, Assuming the administrator of the
- installation has enabled this feature. Big Files are stored directly on
- disk instead of in the database, and can be deleted when it is no longer
- needed. The maximum size of a Big File is normally larger than the
- maximum size of a regular attachment.
- </para>
+ </para>
</section>
</section>
</para>
</section>
- <section id="whining">
- <title>Whining</title>
-
- <para>
- Whining is a feature in Bugzilla that can regularly annoy users at
- specified times. Using this feature, users can execute saved searches
- at specific times (i.e. the 15th of the month at midnight) or at
- regular intervals (i.e. every 15 minutes on Sundays). The results of the
- searches are sent to the user, either as a single email or as one email
- per bug, along with some descriptive text.
- </para>
-
- <warning>
- <para>
- Throughout this section it will be assumed that all users are members
- of the bz_canusewhines group, membership in which is required in order
- to use the Whining system. You can easily make all users members of
- the bz_canusewhines group by setting the User RegExp to ".*" (without
- the quotes).
- </para>
-
- <para>
- Also worth noting is the bz_canusewhineatothers group. Members of this
- group can create whines for any user or group in Bugzilla using a
- extended form of the whining interface. Features only available to
- members of the bz_canusewhineatothers group will be noted in the
- appropriate places.
- </para>
- </warning>
-
- <note>
- <para>
- For whining to work, a special Perl script must be executed at regular
- intervals. More information on this is available in
- <xref linkend="installation-whining"/>.
- </para>
- </note>
-
- <note>
- <para>
- This section does not cover the whineatnews.pl script. See
- <xref linkend="installation-whining-cron"/> for more information on
- The Whining Cron.
- </para>
- </note>
-
- <section id="whining-overview">
- <title>The Event</title>
-
- <para>
- The whining system defines an "Event" as one or more queries being
- executed at regular intervals, with the results of said queries (if
- there are any) being emailed to the user. Events are created by
- clicking on the "Add new event" button.
- </para>
-
- <para>
- Once a new event is created, the first thing to set is the "Email
- subject line". The contents of this field will be used in the subject
- line of every email generated by this event. In addition to setting a
- subject, space is provided to enter some descriptive text that will be
- included at the top of each message (to help you in understanding why
- you received the email in the first place).
- </para>
-
- <para>
- The next step is to specify when the Event is to be run (the Schedule)
- and what searches are to be performed (the Queries).
- </para>
-
- </section>
-
- <section id="whining-schedule">
- <title>Whining Schedule</title>
-
- <para>
- Each whining event is associated with zero or more schedules. A
- schedule is used to specify when the query (specified below) is to be
- run. A new event starts out with no schedules (which means it will
- never run, as it is not scheduled to run). To add a schedule, press
- the "Add a new schedule" button.
- </para>
-
- <para>
- Each schedule includes an interval, which you use to tell Bugzilla
- when the event should be run. An event can be run on certain days of
- the week, certain days of the month, during weekdays (defined as
- Monday through Friday), or every day.
- </para>
-
- <warning>
- <para>
- Be careful if you set your event to run on the 29th, 30th, or 31st of
- the month, as your event may not run exactly when expected. If you
- want your event to run on the last day of the month, select "Last day
- of the month" as the interval.
- </para>
- </warning>
-
- <para>
- Once you have specified the day(s) on which the event is to be run, you
- should now specify the time at which the event is to be run. You can
- have the event run at a certain hour on the specified day(s), or
- every hour, half-hour, or quarter-hour on the specified day(s).
- </para>
-
- <para>
- If a single schedule does not execute an event as many times as you
- would want, you can create another schedule for the same event. For
- example, if you want to run an event on days whose numbers are
- divisible by seven, you would need to add four schedules to the event,
- setting the schedules to run on the 7th, 14th, 21st, and 28th (one day
- per schedule) at whatever time (or times) you choose.
- </para>
-
- <note>
- <para>
- If you are a member of the bz_canusewhineatothers group, then you
- will be presented with another option: "Mail to". Using this you
- can control who will receive the emails generated by this event. You
- can choose to send the emails to a single user (identified by email
- address) or a single group (identified by group name). To send to
- multiple users or groups, create a new schedule for each additional
- user/group.
- </para>
- </note>
- </section>
-
- <section id="whining-query">
- <title>Whining Queries</title>
-
- <para>
- Each whining event is associated with zero or more queries. A query is
- a saved search that is executed on the schedule specified (see above).
- You start out with zero queries attached to the event (which means that
- the event will not run, as there will never be any results to return).
- To add a query, press the "Add a new query" button.
- </para>
-
- <para>
- The first field to examine in your new query is the Sort field. Queries
- are executed, and results returned, in the order specified by the Sort
- field. Queries with lower Sort values will run before queries with
- higher Sort values.
- </para>
-
- <para>
- The next field to examine is the Search field. This is where you
- choose the actual search that is to be run. Instead of defining search
- parameters here, you are asked to choose from the list of saved
- searches (the same list that appears at the bottom of every Bugzilla
- page). You are only allowed to choose from searches that you have
- saved yourself (the default saved search, "My Bugs", is not a valid
- choice). If you do not have any saved searches, you can take this
- opportunity to create one (see <xref linkend="list"/>).
- </para>
-
- <note>
- <para>
- When running queries, the whining system acts as if you are the user
- executing the query. This means that the whining system will ignore
- bugs that match your query, but that you can not access.
- </para>
- </note>
-
- <para>
- Once you have chosen the saved search to be executed, give the query a
- descriptive title. This title will appear in the email, above the
- results of the query. If you choose "One message per bug", the query
- title will appear at the top of each email that contains a bug matching
- your query.
- </para>
-
- <para>
- Finally, decide if the results of the query should be sent in a single
- email, or if each bug should appear in its own email.
- </para>
-
- <warning>
- <para>
- Think carefully before checking the "One message per bug" box. If
- you create a query that matches thousands of bugs, you will receive
- thousands of emails!
- </para>
- </warning>
- </section>
-
- <section>
- <title>Saving Your Changes</title>
-
- <para>
- Once you have defined at least one schedule, and created at least one
- query, go ahead and "Update/Commit". This will save your Event and make
- it available for immediate execution.
- </para>
-
- <note>
- <para>
- If you ever feel like deleting your event, you may do so using the
- "Remove Event" button in the upper-right corner of each Event. You
- can also modify an existing event, so long as you "Update/Commit"
- after completing your modifications.
- </para>
- </note>
- </section>
-
- </section>
-
</chapter>
<!-- Keep this comment at the end of the file
projects / thirdparty / bugzilla.git / commitdiff
