summaryrefslogtreecommitdiffstats
path: root/docs/en/xml
diff options
context:
space:
mode:
authorjocuri%softhome.net <>2008-04-04 13:47:30 +0200
committerjocuri%softhome.net <>2008-04-04 13:47:30 +0200
commit990c3d52a7207e0ce7775dc74494422bd95207b3 (patch)
tree501d6d9f4974bf7d09c35545e8946a38ab67a4d5 /docs/en/xml
parentf6e0be5a458d740f29632beceb5b1511a1fb9011 (diff)
downloadbugzilla-990c3d52a7207e0ce7775dc74494422bd95207b3.tar.gz
bugzilla-990c3d52a7207e0ce7775dc74494422bd95207b3.tar.xz
Documentation patch for bug 198020: provide admin docs for flags; patch by Shane H. W. Travis <travis@sedsystems.ca>; r=myk.
Diffstat (limited to 'docs/en/xml')
-rw-r--r--docs/en/xml/administration.xml411
1 files changed, 411 insertions, 0 deletions
diff --git a/docs/en/xml/administration.xml b/docs/en/xml/administration.xml
index f247108ae..e23a27a67 100644
--- a/docs/en/xml/administration.xml
+++ b/docs/en/xml/administration.xml
@@ -581,6 +581,417 @@
</orderedlist>
</section>
+ <section id="flags">
+ <title>Flags</title>
+
+ <para>
+ Flags are a way to attach a specific status to a bug or attachment,
+ either <quote>+</quote> or <quote>-</quote>. The meaning of these symbols depends on the text
+ the flag itself, but contextually they could mean pass/fail,
+ accept/reject, approved/denied, or even a simple yes/no. If your site
+ allows requestable flags, then users may set a flag to <quote>?</quote> as a
+ request to another user that they look at the bug/attachment, and set
+ the flag to its correct status.
+ </para>
+
+ <section id="flags-simpleexample">
+ <title>A Simple Example</title>
+
+ <para>
+ A developer might want to ask their manager,
+ <quote>Should we fix this bug before we release version 2.0?</quote>
+ They might want to do this for a <emphasis>lot</emphasis> of bugs,
+ so it would be nice to streamline the process...
+ </para>
+ <para>
+ In Bugzilla, it would work this way:
+ <orderedlist>
+ <listitem>
+ <para>
+ The Bugzilla administrator creates a flag type called
+ <quote>blocking2.0</quote> that shows up on all bugs in
+ your product.
+ </para>
+
+ <para>
+ It shows up on the <quote>Show Bug</quote> screen
+ as the text <quote>blocking2.0</quote> with a drop-down box next
+ to it. The drop-down box contains four values: an empty space,
+ <quote>?</quote>, <quote>-</quote>, and <quote>+</quote>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The developer sets the flag to <quote>?</quote>.</para>
+ </listitem>
+ <listitem>
+ <para>
+ The manager sees the <computeroutput>blocking2.0</computeroutput>
+ flag with a <quote>?</quote> value.
+ </para>
+ </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>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Now, every Bugzilla user who looks at the bug knows whether or
+ not the bug needs to be fixed before release of version 2.0.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+
+ </section>
+
+ <section id="flags-about">
+ <title>About Flags</title>
+
+ <section id="flag-values">
+ <title>Values</title>
+ <para>
+ Flags can have three values:
+ <variablelist>
+ <varlistentry>
+ <term><computeroutput>?</computeroutput></term>
+ <listitem><simpara>
+ A user is requesting that a status be set. (Think of it as 'A question is being asked'.)
+ </simpara></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><computeroutput>-</computeroutput></term>
+ <listitem><simpara>
+ 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>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <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.
+ </para>
+ </section>
+ </section>
+
+ <section id="flag-askto">
+ <title>Using flag requests</title>
+ <para>
+ If a flag has been defined as 'requestable',
+ users are allowed to set the flag's status to <quote>?</quote>.
+ This status indicates that someone (aka <quote>the requester</quote> is asking
+ for someone else to set the flag to either <quote>+</quote> or <quote>-</quote>.
+ </para>
+ <para>
+ If a flag has been defined as 'specifically requestable',
+ a text box will appear next to the flag into which the requester may
+ enter a Bugzilla username. That named person (aka <quote>the requestee</quote>)
+ will receive an email notifying them of the request, and pointing them
+ to the bug/attachment in question.
+ </para>
+ <para>
+ If a flag has <emphasis>not</emphasis> been defined as 'specifically requestable',
+ then no such text-box will appear. A request to set this flag cannot be made of
+ any specific individual, but must be asked <quote>to the wind</quote>.
+ A requester may <quote>ask the wind</quote> on any flag simply by leaving the text-box blank.
+ </para>
+ </section>
+
+ <section id="flag-types">
+ <title>Two Types of Flags</title>
+
+ <para>
+ Flags can go in two places: on an attachment, or on a bug.
+ </para>
+
+ <section id="flag-type-attachment">
+ <title>Attachment Flags</title>
+
+ <para>
+ Attachment flags are used to ask a question about a specific
+ attachment on a bug.
+ </para>
+ <para>
+ Many Bugzilla installations use this to
+ request that one developer <quote>review</quote> another
+ developer's code before they check it in. They attach the code to
+ a bug report, and then set a flag on that attachment called
+ <quote>review</quote> to
+ <computeroutput>review?boss@domain.com</computeroutput>.
+ boss@domain.com is then notified by email that
+ he has to check out that attachment and approve it or deny it.
+ </para>
+
+ <para>
+ For a Bugzilla user, attachment flags show up in two
+ places:
+ <orderedlist>
+ <listitem>
+ <para>
+ On the list of attachments in the <quote>Show Bug</quote>
+ screen, you can see the current state of any flags that
+ have been set to ?, +, or -. You can see who asked about
+ the flag (the requester), and who is being asked (the
+ requestee).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ When you <quote>Edit</quote> an attachment, you can
+ see any settable flag, along with any flags that have
+ already been set. This <quote>Edit Attachment</quote>
+ screen is where you set flags to ?, -, +, or unset them.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+
+ </section>
+
+ <section id="flag-type-bug">
+ <title>Bug Flags</title>
+
+ <para>
+ Bug flags are used to set a status on the bug itself. You can
+ see Bug Flags in the <quote>Show Bug</quote> screen
+ (<filename>editbug.cgi</filename>).
+ </para>
+ <para>
+ Only users with the ability to edit the bug may
+ set flags on bugs. This includes the owner, reporter, and
+ any user with the <computeroutput>editbugs</computeroutput>
+ permission.
+ </para>
+ </section>
+
+ </section>
+
+ <section id="flags-admin">
+ <title>Administering Flags</title>
+
+ <para>
+ If you have the <quote>editcomponents</quote> permission, you will
+ have <quote>Edit: ... | Flags | ...</quote> in your page footer.
+ Clicking on that link will bring you to the <quote>Administer
+ Flag Types</quote> page. Here, you can select whether you want
+ to create (or edit) a Bug flag, or an Attachment flag.
+ </para>
+ <para>
+ No matter which you choose, the interface is the same, so we'll
+ just go over it once.
+ </para>
+
+ <section id="flags-create">
+ <title>Creating a Flag</title>
+
+ <para>
+ When you click on the <quote>Create a Flag Type for...</quote>
+ link, you will be presented with a form. Here is what the felds in
+ the form mean:
+ </para>
+
+ <section id="flags-create-field-name">
+ <title>Name</title>
+ <para>
+ This is the name of the flag. This will be displayed
+ to Bugzilla users who are looking at or setting the flag.
+ The name may consist of any valid Unicode character.
+ </para>
+ </section>
+
+ <section id="flags-create-field-description">
+ <title>Description</title>
+ <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
+ can be as long as you like, and can contain any character you want.
+ </para>
+ </section>
+
+ <section id="flags-create-field-category">
+ <title>Category</title>
+
+ <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.
+ </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
+ <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>
+
+ <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>
+
+ <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>
+ </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.
+ </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>.
+ </para>
+ </section>
+
+ <section id="flags-create-field-sortkey">
+ <title>Sort Key</title>
+ <para>
+ Flags normally show up in alphabetical order. If you want them to
+ show up in a different order, you can use this key set the order on each flag.
+ Flags with a lower sort key will appear before flags with a higher
+ sort key. Flags that have the same sort key will be sorted alphabetically,
+ but they will still be after flags with a lower sort key, and before flags
+ with a higher sort key.
+ </para>
+ <para>
+ <emphasis>Example:</emphasis> I have AFlag (Sort Key 100), BFlag (Sort Key 10),
+ CFlag (Sort Key 10), and DFlag (Sort Key 1). These show up in
+ the order: DFlag, BFlag, CFlag, AFlag.
+ </para>
+ </section>
+
+ <section id="flags-create-field-active">
+ <title>Active</title>
+ <para>
+ Sometimes, you might want to keep old flag information in the
+ 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.
+ 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>
+
+ <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 -->
+
+ <!-- XXX We should add a "Uses of Flags" section, here, with examples. -->
+
+ </section> <!-- flags -->
+
<section id="voting">
<title>Voting</title>