summaryrefslogtreecommitdiffstats
path: root/docs/en/rst/using/preferences.rst
blob: f0ffc5c1a52bb9af349bbc4e4be4c428c9c5820c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
.. _user-preferences:

User Preferences
################

Once logged in, you can customize various aspects of
Bugzilla via the "Preferences" link in the page footer.
The preferences are split into a number of tabs, detailed in the sections
below.

.. _generalpreferences:

General Preferences
===================

This tab allows you to change several default settings of Bugzilla.
Administrators have the power to remove preferences from this list, so you
may not see all the preferences available.

Each preference should be self-explanatory.

.. _emailpreferences:

Email Preferences
=================

This tab allows you to enable or disable email notification on
specific events.

In general, users have almost complete control over how much (or
how little) email Bugzilla sends them. If you want to receive the
maximum amount of email possible, click the ``Enable All
Mail`` button. If you don't want to receive any email from
Bugzilla at all, click the ``Disable All Mail`` button.

.. note:: A Bugzilla administrator can stop a user from receiving
   bugmail by clicking the ``Bugmail Disabled`` checkbox
   when editing the user account. This is a drastic step
   best taken only for disabled accounts, as it overrides
   the user's individual mail preferences.

There are two global options -- ``Email me when someone
asks me to set a flag`` and ``Email me when someone
sets a flag I asked for``. These define how you want to
receive bugmail with regards to flags. Their use is quite
straightforward: enable the checkboxes if you want Bugzilla to
send you mail under either of the above conditions.

If you'd like to set your bugmail to something besides
'Completely ON' and 'Completely OFF', the
``Field/recipient specific options`` table
allows you to do just that. The rows of the table
define events that can happen to a bug -- things like
attachments being added, new comments being made, the
priority changing, etc. The columns in the table define
your relationship with the bug - reporter, assignee, QA contact (if enabled)
or CC list member.

To fine-tune your bugmail, decide the events for which you want
to receive bugmail; then decide if you want to receive it all
the time (enable the checkbox for every column) or only when
you have a certain relationship with a bug (enable the checkbox
only for those columns). For example, if you didn't want to
receive mail when someone added themselves to the CC list, you
could uncheck all the boxes in the ``CC Field Changes``
line. As another example, if you never wanted to receive email
on bugs you reported unless the bug was resolved, you would
uncheck all boxes in the ``Reporter`` column
except for the one on the ``The bug is resolved or
verified`` row.

.. note:: Bugzilla adds the ``X-Bugzilla-Reason`` header to
   all bugmail it sends, describing the recipient's relationship
   (AssignedTo, Reporter, QAContact, CC, or Voter) to the bug.
   This header can be used to do further client-side filtering.

Bugzilla has a feature called ``User Watching``.
When you enter one or more comma-delineated user accounts (usually email
addresses) into the text entry box, you will receive a copy of all the
bugmail those users are sent (security settings permitting).
This powerful functionality enables seamless transitions as developers
change projects or users go on holiday.

Each user listed in the ``Users watching you`` field
has you listed in their ``Users to watch`` list
and can get bugmail according to your relationship to the bug and
their ``Field/recipient specific options`` setting.

Lastly, you can define a list of bugs on which you no longer wish to receive
any email, ever. (You can also add bugs to this list individually by checking
the "Ignore Bug Mail" checkbox on the bug page for that bug.) This is useful
for ignoring bugs where you are the reporter, as that's a role it's not
possible to stop having.

.. _saved-searches:

Saved Searches
==============

On this tab you can view and run any Saved Searches that you have
created, and any Saved Searches that other members of the group
defined in the :param:`querysharegroup` parameter have shared.
Saved Searches can be added to the page footer from this screen.
If somebody is sharing a Search with a group they are allowed to
:ref:`assign users to <groups>`, the sharer may opt to have
the Search show up in the footer of the group's direct members by default.

.. _account-information:

Account Information
===================

On this tab, you can change your basic account information,
including your password, email address and real name. For security
reasons, in order to change anything on this page you must type your
*current* password into the ``Password``
field at the top of the page.
If you attempt to change your email address, a confirmation
email is sent to both the old and new addresses with a link to use to
confirm the change. This helps to prevent account hijacking.

.. _api-keys:

API Keys
========

API keys allow you to give a "token" to some external software so it can log
in to the WebService API as you without knowing your password. You can then
revoke that token if you stop using the web service, and you don't need to
change your password everywhere.

You can create more than one API key if required. Each API key has an optional
description which can help you record what it is used for.

On this page, you can unrevoke, revoke and change the description of existing
API keys for your login. A revoked key means that it cannot be used. The
description is optional and purely for your information.

You can also create a new API key by selecting the checkbox under the 'New
API key' section of the page.

.. _permissions:

Permissions
===========

This is an informational page which outlines your current
permissions on this installation of Bugzilla.

A complete list of available permissions in a default install of Bugzilla is
below. Your administrator may have defined other permissions. Only users with
the *editusers* permission can change the permissions of other users.

admin
    User is an administrator, which (in normal circumstances) means they can
    do anything.

tweakparams
    Permits user to change administration :ref:`Parameters <parameters>`, and
    to enable, disable and change the default value of
    :ref:`General Preferences <generalpreferences>`.

bz_sudoers
    Permits user to impersonate and perform actions as other users. This is
    useful for admins to reproduce problems with Bugzilla, such as permissions
    problems, that other users see.

bz_sudo_protect
    Indicates user cannot be impersonated by other users who have the
    *bz_sudoers* permission.

creategroups
    Permits user to create, delete and edit permission groups.

editclassifications
    Permits user to create, delete and edit classifications.

editcomponents
    Permits user to create, delete and edit products, components,
    versions, milestones and flag types.

    This capability can also be given on a per-product basis.

editkeywords
    Permits user to create, delete and edit keywords.

editusers
    Permits user to create, disable and edit users.

canconfirm
    Permits user to confirm a bug (move it from UNCONFIRMED to
    another status).

    This permission is only used if you are using the UNCONFIRMED status in
    any products. The *editbugs* permission implies this permission.

    This capability can also be given on a per-product basis.

editbugs
    Permits user to edit all fields on a bug. Without this permission, users
    can only edit bugs where they are the reporter or the assignee, or add
    comments.

    This capability can also be given on a per-product basis.

bz_canusewhines
    Permits user to configure whine reports to be sent to themselves.

bz_canusewhineatothers
    Permits user to configure whine reports to be sent to other users.

bz_quip_moderators
    Permits user to moderate the list of quips (pithy sayings at the top of
    bug lists).