Fields and Keywords docs
parent
f190093fc9
commit
d921f2ab87
|
@ -2739,114 +2739,173 @@ of the excluded type. If another flag type with the same name exists in the excl
|
||||||
product/component, Bugzilla changes all existing flags to that type. If you just
|
product/component, Bugzilla changes all existing flags to that type. If you just
|
||||||
'disable' the flag, Bugzilla does not delete and does not retarget existing flags.
|
'disable' the flag, Bugzilla does not delete and does not retarget existing flags.
|
||||||
|
|
||||||
[[keywords]]
|
=== Bug Fields
|
||||||
=== Keywords
|
|
||||||
|
|
||||||
The administrator can define keywords which can be used to tag and
|
In Bugzilla4Intranet, it is not only possible to create Custom Fields for bugs,
|
||||||
categorise bugs. For example, the keyword "regression" is commonly used.
|
but it's also possible to tweak some properties of standard ones. For example,
|
||||||
A company might have a policy stating all regressions
|
enabling/disabling fields like Alias, Classification and et cetera is done
|
||||||
must be fixed by the next release - this keyword can make tracking those
|
using the "Disabled" property of these fields, not via the 'use*' parameters
|
||||||
bugs much easier.
|
like in the original Bugzilla.
|
||||||
|
|
||||||
Keywords are global, rather than per-product. If the administrator changes
|
Both custom and normal fields are accessible from the 'Administration -> Bug Fields' page.
|
||||||
a keyword currently applied to any bugs, the keyword cache must be rebuilt
|
|
||||||
using the <<sanitycheck,Sanity Check>> script. Currently keywords can not
|
|
||||||
be marked obsolete to prevent future usage.
|
|
||||||
|
|
||||||
Keywords can be created, edited or deleted by clicking the "Keywords"
|
|
||||||
link in the admin page. There are two fields for each keyword - the keyword
|
|
||||||
itself and a brief description. Once created, keywords can be selected
|
|
||||||
and applied to individual bugs in that bug's "Details" section.
|
|
||||||
|
|
||||||
[[custom-fields]]
|
|
||||||
=== Custom Fields
|
|
||||||
|
|
||||||
The release of Bugzilla 3.0 added the ability to create Custom Fields.
|
|
||||||
Custom Fields are treated like any other field - they can be set in bugs
|
Custom Fields are treated like any other field - they can be set in bugs
|
||||||
and used for search queries. Administrators should keep in mind that
|
and used for search queries. Administrators should keep in mind that
|
||||||
adding too many fields can make the user interface more complicated and
|
adding too many fields can make the user interface more complicated and
|
||||||
harder to use. Custom Fields should be added only when necessary and with
|
harder to use. Custom Fields should be added only when necessary and with
|
||||||
careful consideration.
|
careful consideration.
|
||||||
|
|
||||||
[TIP]
|
TIP: Before adding a Custom Field, make sure that Bugzilla can not already
|
||||||
====
|
|
||||||
Before adding a Custom Field, make sure that Bugzilla can not already
|
|
||||||
do the desired behavior. Many Bugzilla options are not enabled by
|
do the desired behavior. Many Bugzilla options are not enabled by
|
||||||
default, and many times Administrators find that simply enabling
|
default, and many times Administrators find that simply enabling
|
||||||
certain options that already exist is sufficient.
|
certain options that already exist is sufficient.
|
||||||
====
|
|
||||||
|
|
||||||
Administrators can manage Custom Fields using the
|
==== Tweaking Standard Fields
|
||||||
"Custom Fields" link on the Administration page. The Custom
|
|
||||||
Fields administration page displays a list of Custom Fields, if any exist,
|
You can tweak the behaviour of standard Bugzilla fields in various ways: enable/disable them,
|
||||||
and a link to "Add a new custom field".
|
set default values, allow or deny empty value, or even make some of them depend on other fields.
|
||||||
|
|
||||||
|
For example, you can enable/disable Alias, Classification, Platform, Operating System,
|
||||||
|
QA Contact, Target Milestone, Status Whiteboard and See Also fields.
|
||||||
|
|
||||||
|
To change properties of a standard field, select it in the table under the 'Standard fields'
|
||||||
|
heading. You can change any property shown on the field form; properties are hidden
|
||||||
|
if it is not possible to edit them.
|
||||||
|
|
||||||
|
==== Field Properties
|
||||||
|
|
||||||
|
Name::
|
||||||
|
The name of the field in the database, used internally. This name
|
||||||
|
must begin with "cf_" for custom fields to prevent confusion with
|
||||||
|
standard fields. If "cf_" is omitted, it will be automatically added
|
||||||
|
to the name entered.
|
||||||
|
|
||||||
|
Title::
|
||||||
|
A brief string which is used as the label for the Custom Field.
|
||||||
|
That is the string that users will see, and should be short and explicit.
|
||||||
|
For standard fields, the description does not really affect the displayed field label.
|
||||||
|
|
||||||
|
Sortkey::
|
||||||
|
Integer that determines in which order Custom Fields are displayed in the user
|
||||||
|
interface when viewing bugs and bug history, and in the e-mail notification messages.
|
||||||
|
Fields with lower values are displayed first.
|
||||||
|
|
||||||
|
Type::
|
||||||
|
+
|
||||||
|
--
|
||||||
|
The type of field. You can choose type when creating a custom field, and you can't
|
||||||
|
change it when the field already exists. There are several types available:
|
||||||
|
|
||||||
|
Free Text::
|
||||||
|
A single line edit field for entering free text. Maximum length of values of such fields is 255 characters.
|
||||||
|
Large Text Box::
|
||||||
|
A multiple line box (textarea) for entering free text. Values of such fields may be up to several megabytes long.
|
||||||
|
Numeric::
|
||||||
|
A field that allows only numeric (decimal floating point) values.
|
||||||
|
Drop Down::
|
||||||
|
A list box where only one option can be selected.
|
||||||
|
After creating this field, it must be edited to add the selection options. See
|
||||||
|
<<edit-values-list,Viewing/Editing legal values>> for information about editing legal values.
|
||||||
|
Multiple-Selection Box::
|
||||||
|
A list box where multiple options can be selected.
|
||||||
|
After creating this field, it must be edited to add the selection options,
|
||||||
|
just like the 'Drop Down' fields.
|
||||||
|
Date/Time::
|
||||||
|
A date field. This field appears with a calendar widget for choosing the date.
|
||||||
|
Bug ID::
|
||||||
|
A field that is a reference to bug. Besides just appearing in the search form,
|
||||||
|
Bug ID fields also allow to use properties of the bug they reference to in searches.
|
||||||
|
For example, if there is a Bug ID field named "External Bug", the search form will also
|
||||||
|
have "External Bug Summary", "External Bug Status" and similar as options.
|
||||||
|
Bug ID reverse::
|
||||||
|
A pseudo-field that shows back-references for an existing Bug ID field.
|
||||||
|
Only one "reverse" field may be created for a single Bug ID field; you must
|
||||||
|
specify that Bug ID field in the "Direct Bug ID field" editbox while creating
|
||||||
|
a "reverse" field. +
|
||||||
|
For example, for an existing Bug ID field named "External Bug", the reverse field
|
||||||
|
should be named "Internal Bugs" (not just "bug" because multiple bugs may reference
|
||||||
|
to a single bug as a value of the "External Bug" field).
|
||||||
|
External URL::
|
||||||
|
A field that links to a URL generated from a given template by replacing "$1" with
|
||||||
|
the field value. For example, you may use this type to reference to a single bug in
|
||||||
|
an external bugtracker; for the case of Bugzilla4Intranet GitHub issues you should
|
||||||
|
specify "https://github.com/vitalif/bugzilla-4intranet/issues/$1" URL template.
|
||||||
|
--
|
||||||
|
|
||||||
|
Deps::
|
||||||
|
Effective only for 'Bug ID' fields, this property specifies if the field value should be
|
||||||
|
automatically added to the bug dependencies. You may choose "Add field value to blocked"
|
||||||
|
or "Add field value to blockers" here.
|
||||||
|
|
||||||
|
URL::
|
||||||
|
Only for 'External URL' fields, this property specifies URL template used in the field.
|
||||||
|
|
||||||
|
Displayed in bugmail for new bugs::
|
||||||
|
A flag (checkbox) that determines whether the value set on this field should appear in
|
||||||
|
the "New Bug" bugmail when the bug is filed.
|
||||||
|
|
||||||
|
Is copied into the cloned bug::
|
||||||
|
A flag (checkbox) that determines whether the value of this field should be copied
|
||||||
|
to the cloned bugs.
|
||||||
|
|
||||||
|
Is disabled::
|
||||||
|
A flag (checkbox) that determines whether this field should be displayed and used at all.
|
||||||
|
Disabled Custom Fields are hidden from the UI. You must disable Custom Fields before
|
||||||
|
deleting them.
|
||||||
|
|
||||||
|
Default value::
|
||||||
|
The global default value for this field. This, for example, replaces old 'defaultpriority',
|
||||||
|
'defaultseverity' and similar properties of the original Bugzilla. The default value
|
||||||
|
can only be set after creating the field and filling the legal values for selectbox fields.
|
||||||
|
|
||||||
|
Allow empty value::
|
||||||
|
A flag (checkbox) that determines whether it is possible to leave this field empty in
|
||||||
|
newly created and edited bugs. Note that multiple-selection boxes always allow empty values,
|
||||||
|
and because "reverse" bug ID fields don't really store any data, it's also impossible
|
||||||
|
to make them nullable or non-nullable.
|
||||||
|
|
||||||
|
Also there are some properties that specify field dependencies. You can make any field
|
||||||
|
depend on other select or multi-select field in various ways:
|
||||||
|
|
||||||
|
Show/hide the field depending on the value of::
|
||||||
|
After you specify another field here (for example, Product), you'll be able to enable or disable
|
||||||
|
the field you are editing for every value of that field (for example, per Product).
|
||||||
|
|
||||||
|
Allow empty value depending on the value of::
|
||||||
|
This dependency allows you to enable or disable empty value of edited field for each value
|
||||||
|
of field selected as the dependency. Requires the "Allow empty value" property enabled.
|
||||||
|
|
||||||
|
Clone field depending on the value of::
|
||||||
|
This dependency allows you to enable or disable copying of edited field value for each value
|
||||||
|
of field selected as the dependency. Requires the "Is copied into the cloned bug" property enabled.
|
||||||
|
|
||||||
|
Make default value dependent on the value of::
|
||||||
|
This dependency allows you to choose different default values for different values
|
||||||
|
of field selected as the dependency. Default values only have effect on the bug creation form.
|
||||||
|
|
||||||
|
Field that controls the values that appear in this field::
|
||||||
|
This dependency allows you to have different legal values for different values
|
||||||
|
of field selected as the dependency.
|
||||||
|
|
||||||
|
NOTE: A common usage of dependencies is to make field properties depend on Product or Component. However,
|
||||||
|
any select or multi-select field, including custom ones, may be used as the dependency field.
|
||||||
|
|
||||||
[[add-custom-fields]]
|
|
||||||
==== Adding Custom Fields
|
==== Adding Custom Fields
|
||||||
|
|
||||||
To add a new Custom Field, click the "Add a new custom field" link. This
|
To add a new Custom Field, click the "Add a new custom field" link, fill the form and press "Create".
|
||||||
page displays several options for the new field, described below.
|
|
||||||
|
|
||||||
The following attributes must be set for each new custom field:
|
WARNING: Creating most fields implies database schema modifications which can take some time on
|
||||||
|
big bug databases. During that time your Bugzilla4Intranet will look "hung up" for users.
|
||||||
|
However, online creation won't result in any runtime errors, as in the original Bugzilla, so
|
||||||
|
it's usually possible to create the new fields without long downtime.
|
||||||
|
|
||||||
* _Name:_
|
|
||||||
The name of the field in the database, used internally. This name
|
|
||||||
MUST begin with "cf_" to prevent confusion with
|
|
||||||
standard fields. If this string is omitted, it will
|
|
||||||
be automatically added to the name entered.
|
|
||||||
|
|
||||||
* _Description:_
|
|
||||||
A brief string which is used as the label for this Custom Field.
|
|
||||||
That is the string that users will see, and should be
|
|
||||||
short and explicit.
|
|
||||||
|
|
||||||
* _Type:_
|
|
||||||
The type of field to create. There are
|
|
||||||
several types available:
|
|
||||||
|
|
||||||
** Large Text Box: A multiple line box for entering free text.
|
|
||||||
** Free Text: A single line box for entering free text.
|
|
||||||
** Multiple-Selection Box: A list box where multiple options
|
|
||||||
can be selected. After creating this field, it must be edited
|
|
||||||
to add the selection options. See <<edit-values-list,Viewing/Editing legal values>> for information about
|
|
||||||
editing legal values.
|
|
||||||
** Drop Down: A list box where only one option can be selected.
|
|
||||||
After creating this field, it must be edited to add the
|
|
||||||
selection options. See
|
|
||||||
<<edit-values-list,Viewing/Editing legal values>> for information about
|
|
||||||
editing legal values.
|
|
||||||
** Date/Time: A date field. This field appears with a
|
|
||||||
calendar widget for choosing the date.
|
|
||||||
|
|
||||||
* _Sortkey:_
|
|
||||||
Integer that determines in which order Custom Fields are
|
|
||||||
displayed in the User Interface, especially when viewing a bug.
|
|
||||||
Fields with lower values are displayed first.
|
|
||||||
|
|
||||||
* _Can be set on bug creation:_
|
|
||||||
Boolean that determines whether this field can be set on
|
|
||||||
bug creation. If not selected, then a bug must be created
|
|
||||||
before this field can be set. See <<bugreports,Filing Bugs>>
|
|
||||||
for information about filing bugs.
|
|
||||||
|
|
||||||
* _Displayed in bugmail for new bugs:_
|
|
||||||
Boolean that determines whether the value set on this field
|
|
||||||
should appear in bugmail when the bug is filed. This attribute
|
|
||||||
has no effect if the field cannot be set on bug creation.
|
|
||||||
|
|
||||||
* _Is obsolete:_
|
|
||||||
Boolean that determines whether this field should
|
|
||||||
be displayed at all. Obsolete Custom Fields are hidden.
|
|
||||||
|
|
||||||
[[edit-custom-fields]]
|
|
||||||
==== Editing Custom Fields
|
==== Editing Custom Fields
|
||||||
|
|
||||||
As soon as a Custom Field is created, its name and type cannot be
|
As soon as a Custom Field is created, its name and type cannot be
|
||||||
changed. If this field is a drop down menu, its legal values can
|
changed. If this field is a drop down menu, its legal values can
|
||||||
be set as described in <<edit-values-list,Viewing/Editing legal values>>. All
|
be set as described in <<edit-values-list,Viewing/Editing legal values>>. All
|
||||||
other attributes can be edited as described above.
|
other attributes can be edited just like during creation.
|
||||||
|
|
||||||
[[delete-custom-fields]]
|
|
||||||
==== Deleting Custom Fields
|
==== Deleting Custom Fields
|
||||||
|
|
||||||
Only custom fields which are marked as obsolete, and which never
|
Only custom fields which are marked as obsolete, and which never
|
||||||
|
@ -2860,25 +2919,58 @@ to hide it from the user interface entirely.
|
||||||
[[edit-values]]
|
[[edit-values]]
|
||||||
=== Legal Values
|
=== Legal Values
|
||||||
|
|
||||||
Since Bugzilla 2.20 RC1, legal values for Operating Systems, platforms,
|
In Bugzilla4Intranet, legal values for all standard select fields
|
||||||
bug priorities and severities can be edited from the User Interface
|
(Severity, Priority, OS, Platform, Status and Resolution) can be customized
|
||||||
directly. This means that it is no longer required to manually edit
|
from the field administration UI directly.
|
||||||
_localconfig_. Starting with Bugzilla 2.23.3,
|
|
||||||
the list of valid resolutions can be customized from the same interface.
|
|
||||||
Since Bugzilla 3.1.1 the list of valid bug statuses can be customized
|
|
||||||
as well.
|
|
||||||
|
|
||||||
[[edit-values-list]]
|
[[edit-values-list]]
|
||||||
==== Viewing/Editing legal values
|
==== Viewing/Editing legal values
|
||||||
|
|
||||||
Editing legal values requires "admin" privileges.
|
Editing legal values requires being a member of the 'editvalues' system group.
|
||||||
Select "Legal Values" from the Administration page. A list of all
|
|
||||||
|
Select 'Field Values' from the Administration page. A list of all
|
||||||
fields, both system fields and Custom Fields, for which legal values
|
fields, both system fields and Custom Fields, for which legal values
|
||||||
can be edited appears. Click a field name to edit its legal values.
|
can be edited appears. Click a field name to edit its legal values.
|
||||||
|
|
||||||
There is no limit to how many values a field can have, but each value
|
There is no limit to how many values a field can have, but each value
|
||||||
must be unique to that field. The sortkey is important to display these
|
must be unique to that field.
|
||||||
values in the desired order.
|
|
||||||
|
All legal values have 3 properties:
|
||||||
|
|
||||||
|
Name:: Value name. In Bugzilla4Intranet, maximum name length is 255 characters for all fields.
|
||||||
|
Sortkey:: Used to sort values. Values with smaller numbers are displayed first.
|
||||||
|
Enabled for bugs:: Used to remove old values from the UI while keeping them in the database.
|
||||||
|
|
||||||
|
Values of some fields also have additional properties:
|
||||||
|
|
||||||
|
* Bug Statuses have several semantic flags:
|
||||||
|
+
|
||||||
|
--
|
||||||
|
Is open:: Specifies if a bug in this state hasn't been fixed yet.
|
||||||
|
Is it a confirmed state:: For open states, specifies if a bug in this state is confirmed.
|
||||||
|
By default, this is off only for the UNCONFIRMED state.
|
||||||
|
Is it an assigned state:: Specifies if a bug in this state has someone working on it.
|
||||||
|
There should only one assigned state.
|
||||||
|
|
||||||
|
These flags are used by Bugzilla4Intranet to work with bug statuses correctly regardless of
|
||||||
|
their names.
|
||||||
|
--
|
||||||
|
* Values of the OS and Platform fields have an additional property named 'User Agent Regexp'
|
||||||
|
which is used to guess the value based on HTTP User-Agent header sent by the user browser.
|
||||||
|
As always, these are Perl regexes and you can edit them if you want to change the guessed values.
|
||||||
|
* Keywords have the description in addition to just name.
|
||||||
|
|
||||||
|
If the field values of which you are editing has value dependency field ('Field that controls the
|
||||||
|
values that appear in this field') there will be also a 'Only appears when ... is set to:' multiple-selection
|
||||||
|
box on the field value edit form. You can use it to enable/disable the value for specific values of the
|
||||||
|
dependency field.
|
||||||
|
|
||||||
|
If any other field depends on the one values of which you are editing, the value form will also contain
|
||||||
|
checkboxes or inputs allowing to edit the dependent properties for the value you are editing.
|
||||||
|
|
||||||
|
NOTE: This is usually more convenient to edit dependent properties and values from the
|
||||||
|
dependency value page instead of the page of dependent value, for example, edit the set of values
|
||||||
|
enabled for a specific product from that product's page.
|
||||||
|
|
||||||
[[edit-values-delete]]
|
[[edit-values-delete]]
|
||||||
==== Deleting legal values
|
==== Deleting legal values
|
||||||
|
@ -2894,6 +2986,20 @@ If any of these conditions is not respected, the value cannot be deleted.
|
||||||
The only way to delete these values is to reassign bugs to another value
|
The only way to delete these values is to reassign bugs to another value
|
||||||
and to set another value as default for the field.
|
and to set another value as default for the field.
|
||||||
|
|
||||||
|
=== Keywords
|
||||||
|
|
||||||
|
The administrator can define keywords which can be used to tag and
|
||||||
|
categorise bugs. For example, the keyword "regression" is commonly used.
|
||||||
|
A company might have a policy stating all regressions must be fixed by the
|
||||||
|
next release - this keyword can make tracking those bugs much easier.
|
||||||
|
|
||||||
|
Keywords are global by default, but you may configure them to depend on product
|
||||||
|
or on another select field by setting the value dependency field from the Bug Fields UI.
|
||||||
|
|
||||||
|
In Bugzilla4Intranet, keywords are more similar to tags: if a user specifies a non-existing
|
||||||
|
keyword, Bugzilla asks him to enter a description for it, and the new keyword is created
|
||||||
|
automatically afterwards.
|
||||||
|
|
||||||
[[bug_status_workflow]]
|
[[bug_status_workflow]]
|
||||||
=== Bug Status Workflow
|
=== Bug Status Workflow
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue