198019 - Bugzilla Guide contains no end-user docs for Flags

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect, P2)

Description

[Dave Miller [:justdave]]

It was brought up on the developers list that there aren't any end-user docs for
Flags in the Guide...

Comment 1

[Jacob Steenhagen]

Myk's verbatim response to Sean McAfee's question on the mailing list (so I
don't loose it):

Bug flags are a way to record the status of some characteristic of a bug whose
status can be defined in a boolean fashion.  For example, bug fixes in the
Bugzilla community must be approved by the module owner or his designee before
they can be checked in.  The Bugzilla community uses an "approved" flag in their
own Bugzilla installation (bugzilla.mozilla.org) to indicate whether or not a
bug has been approved for check in.  A bug marked "approved+" has been approved
for check in, while one marked "approved-" has been rejected.

Bug flags are configurable and product/component-specific, so you can add as
many flags as you want and restrict them to certain products or
product/component combinations.  The UI for setting flags on the bug report page
consists of a table listing active flags and a pull-down menu showing their
status.  To change a flag's status, users select a different status from the
pull-down menu.  The options are "" (no value, a.k.a. flag not set), "+" (flag
set positively), "-" (flag set negatively).

Flags are similar to trios of keywords in the functionality they provide but
have the following advantages over keywords;

1. They can be made product/component-specific.
2. They provide a structured UI for making changes instead of making the user
type magical values into an arbitrary text field.
3. They can be deactivated/reactivated without deleting records in the database,
so you can remove a flag from the UI while still keeping the data around in case
it becomes useful again.

Based on your description of the situation, I think bug flags are a good
solution to your problem, with a few potential issues.  First, you mention that
you need a way to prevent the values from being applied to inappropriate
incidents.  Flags can be restricted by product/component combinations, so if
your restrictions are all product/component-based, then this is not a problem. 
Otherwise you would have to add functionality to flags to restrict them by your
other criteria.  Second, flags do not enforce exclusivity, so this feature would
have to be added.

Comment 2

[Dave Miller [:justdave]]

Jake is leaving for a while (Reserve unit got called up), and we don't have a
new docs owner yet.  Anyone interested in helping out, please add
[e-mail] to your watch list in your email preferences in Bugzilla.

Comment 3

[Max Kanat-Alexander]

Oh, whoops, I meant to take this one, too. :-)

Comment 4

[Dave Miller [:justdave]]

yes, by all means :)

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Basic docs checked in to branch and trunk:

Checking in xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.23; previous revision: 1.22
done

Checking in ../../bz218/docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.21.2.2; previous revision: 1.21.2.1
done

Comment 6

[Max Kanat-Alexander]

What exactly is it that got checked in, since there's no attachments to this bug?

Comment 7

[Myk Melez [:myk] [@mykmelez]]

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/webtools/bugzilla/docs/xml&command=DIFF_FRAMESET&file=using.xml&rev1=1.22&rev2=1.23&root=/cvsroot