aboutsummaryrefslogtreecommitdiff
blob: 0c2c81d8c1aa9656b0344d15c5e267ff8529e0c8 (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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
[%# This Source Code Form is subject to the terms of the Mozilla Public
  # License, v. 2.0. If a copy of the MPL was not distributed with this
  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
  #
  # This Source Code Form is "Incompatible With Secondary Licenses", as
  # defined by the Mozilla Public License, v. 2.0.
  #%]

[% PROCESS global/header.html.tmpl
  title = "$terms.Bug Fields"
  bodyclasses = ['narrow_page']
%]

<p>This page describes the various fields that you see 
  on [% terms.abug %].</p>

<table class="field_value_explanation">
  <thead>
  <tr>
    <td id="bug_status">
      <h2>[% field_descs.bug_status FILTER upper FILTER html %]</h2>
    </td>

    <td id="resolution">
      <h2>[% field_descs.resolution FILTER upper FILTER html %]</h2>
    </td>
  </tr>

  <tr>
    <td>The [% field_descs.bug_status FILTER html %] field indicates the 
      current state of a [% terms.bug %]. Only certain status transitions
      are allowed.</td>

    <td>The [% field_descs.resolution FILTER html %] field indicates what
      happened to this [%+ terms.bug %].</td>
  </tr>
  </thead>

  <tbody>
  <tr class="header_row">
    <td colspan="2">Open [% terms.Bugs %]</td>
  </tr>
  <tr>
    <td>
      <dl>
        <dt class="unconfirmed">
          [% display_value("bug_status", "UNCONFIRMED") FILTER html %]
        </dt>
        <dd class="unconfirmed">
          This [% terms.bug %] has recently been added to the database. 
          Nobody has confirmed that this [% terms.bug %] is valid. Users
          who have the "canconfirm" permission set may confirm
          this [% terms.bug %], changing its state to 
          <b>[% display_value("bug_status", "CONFIRMED") FILTER html %]</b>. 
          Or, it may be directly resolved and marked
          <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>.
        </dd>

        <dt class="confirmed">
          [% display_value("bug_status", "CONFIRMED") FILTER html %]
        </dt>
        <dd class="confirmed">
          This [% terms.bug %] is valid and has recently been filed.
          [%+ terms.Bugs %] in this state become 
          <b>[% display_value("bug_status", "IN_PROGRESS") FILTER html %]</b>
          when somebody is working on them, or become resolved and marked
          <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>.
        </dd>

        <dt class="in_progress">
          [% display_value("bug_status", "IN_PROGRESS") FILTER html %]
        </dt>
        <dd class="in_progress">
          This [% terms.bug %] is not yet resolved, but is assigned to the
          proper person who is working on the [% terms.bug %]. From here,
          [%+ terms.bugs %] can be given to another person and become
          <b>[% display_value("bug_status", "CONFIRMED") FILTER html %]</b>, or
          resolved and become 
          <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>.
        </dd>
        
        [% Hook.process('open-status') %]
      </dl>
    </td>

    <td>
      No resolution yet. All [% terms.bugs %] which are in one of
      these "open" states have no resolution set.
    </td>
  </tr>

  <tr class="header_row">
    <td colspan="2">Closed [% terms.Bugs %]</td>
  </tr>

  <tr>
    <td>
      <dl>
        <dt class="resolved">
          [% display_value("bug_status", "RESOLVED") FILTER html %]
        </dt>
        <dd class="resolved">
          A resolution has been performed, and it is awaiting verification by
          QA. From here [% terms.bugs %] are either reopened and given some
          open status, or are verified by an impacted user or QA and marked
          <b>[% display_value("bug_status", "VERIFIED") FILTER html %]</b>.
        </dd>

        <dt class="verified">
          [% display_value("bug_status", "VERIFIED") FILTER html %]
        </dt>
        <dd class="verified">
          QA has looked at the [% terms.bug %] and the resolution and
          agrees that the appropriate resolution has been taken. This is
          the final status for [% terms.bugs %].
        </dd>
        
        [% Hook.process('closed-status') %]
      </dl>
    </td>

    <td>
      <dl>
        <dt class="fixed">
          [% display_value("resolution", "FIXED") FILTER html %]
        </dt>
        <dd class="fixed">
          A fix for this [% terms.bug %] is checked into the tree and 
          tested.
        </dd>

        <dt class="invalid">
          [% display_value("resolution", "INVALID") FILTER html %]
        </dt>
        <dd class="invalid">
          The problem described is not [% terms.abug %].
        </dd>

        <dt class="wontfix">
          [% display_value("resolution", "WONTFIX") FILTER html %]
        </dt>
        <dd class="wontfix">
          The problem described is [% terms.abug %] which will never be 
          fixed.
        </dd>

        <dt class="duplicate">
         [% display_value("resolution", "DUPLICATE") FILTER html %]
        </dt>
        <dd class="duplicate">
          The problem is a duplicate of an existing [% terms.bug %].
          When [% terms.abug %] is marked as a
          <b>[% display_value("resolution", "DUPLICATE") FILTER html %]</b>,
          you will see which [% terms.bug %] it is a duplicate of,
          next to the resolution.
        </dd>

        <dt class="worksforme">
          [% display_value("resolution", "WORKSFORME") FILTER html %]
        </dt>
        <dd class="worksforme">
          All attempts at reproducing this [% terms.bug %] were futile, 
          and reading the code produces no clues as to why the described
          behavior would occur. If more information appears later,
          the [% terms.bug %] can be reopened.
        </dd>

        <dt class="cantfix">
          [% display_value("resolution", "CANTFIX") FILTER html %]
        </dt>
        <dd class="cantfix">
          Fixing this [% terms.bug %] is not possible, and the reasoning
          should be detailed by the closer. Generally speaking, fixing the
          [% terms.bug %] might be technically unfeasible, require an
          extraordinary (unreasonable) amount of effort, be disallowed for
          legal/social reasons, or not within bounds of the current framework.
          If circumstances change later on that affect the justification, the
          [% terms.bug %] can be reopened and reconsidered.
        </dd>

        <dt class="needinfo">
          [% display_value("resolution", "NEEDINFO") FILTER html %]
        </dt>
        <dd class="needinfo">
          Before investigation can proceed further, the reporter needs to
          provide more information. This often includes clarification of
          already posted details, adding missing log files, or running some
          tests to help debug the situation. Once the requested information
          has been provided, the [% terms.bug %] should be re-opened. This
          status is frequently used when the expectation is the submitter
          has disappeared and won't follow up, or to help clear out open
          reports that still need triaging.
        </dd>

        <dt class="testrequest">
          [% display_value("resolution", "TEST-REQUEST") FILTER html %]
        </dt>
        <dd class="testrequest">
          The [% terms.bug %] is thought to be fixed, but we would like
          someone who is affected to verify the fix. If the [% terms.bug %]
          is not actually fixed, then the report should be reopened and more
          details posted (explaining why people believe the [% terms.bug %]
          is not actually fixed).
        </dd>

        <dt class="upstream">
          [% display_value("resolution", "UPSTREAM") FILTER html %]
        </dt>
        <dd class="upstream">
          The requested [% terms.bug %] is considered to be out of the purview
          of the distro and should be submitted/discussed directly with the
          respective upstream project. This could include a number of things
          such as changing default configuration options or behavior, adding
          new options or functionality, or deleting support for older systems.
        </dd>

        <dt class="obsolete">
          [% display_value("resolution", "OBSOLETE") FILTER html %]
        </dt>
        <dd class="obsolete">
          Due to a variety of reasons, the [% terms.bug %] as reported is no
          longer relevant. It might apply to older versions of a package and
          the newer versions rewrote (implicitly fixing) the related code, or
          perhaps support was dropped entirely.
        </dd>
        <dt class="pkgremoved">
          [% display_value("resolution", "PKGREMOVED") FILTER html %]
        </dt>
        <dd class="pkgremoved">
          The [% terms.bug %] is no longer relevant because the affected
          package was removed from the tree.
        </dd>

        [% Hook.process('resolution') %]
      </dl>
    </td>
  </tr>
  </tbody>
</table>

<h2>Other Fields</h2>

[% SET field_help_map = {} %]
[% FOREACH field = bug_fields.keys %]
  [% SET field_desc = field_descs.$field %]
  [% field_help_map.$field_desc = { help  => help_html.$field, 
                                    field => field } %]
[% END %]

[%# This field is not a real one, but its label is visible in bugs. %]

[% field_help_map.Importance = { help  => help_html.importance,
                                 field => "importance" } %]

[%# These are fields that don't need to be documented, either because
  # they have docs somewhere else in the UI, or they don't show up on bugs. 
  # %]
[% SET skip_fields = [ 
  'days_elapsed', 
  'everconfirmed',
  'reporter_accessible',
  'cclist_accessible',
  'bug_group',
  'commenter',
  'owner_idle_time',
  'bug_status',
  'resolution',
] %]

<dl class="field_descriptions">
[% FOREACH field_desc = field_help_map.keys.sort %]
  [% SET field = field_help_map.${field_desc}.field %]
  [% SET field_object = bug_fields.$field %]

  [% NEXT IF field_object.obsolete %]
  [% NEXT IF !user.is_timetracker AND field_object.is_timetracking %]

  [% NEXT IF field == 'status_whiteboard' AND !Param('usestatuswhiteboard') %]
  [% NEXT IF field == 'target_milestone' AND !Param('usetargetmilestone') %]

  [%# For now we don't have help for attachment fields and so on. %]
  [% NEXT IF field.match('\.') %]

  [% NEXT IF skip_fields.contains(field) %]

  <dt id="[% field FILTER html %]">[% field_desc FILTER html %]</dt>
    <dd>
      [% field_help_map.${field_desc}.help FILTER html_light %]
    </dd>
[% END %]
</dl>

[% PROCESS global/footer.html.tmpl %]