~ubuntu-branches/debian/sid/bugzilla/sid

« back to all changes in this revision

Viewing changes to template/en/default/pages/fields.html.tmpl

  • Committer: Bazaar Package Importer
  • Author(s): Raphael Bossek
  • Date: 2008-06-27 22:34:34 UTC
  • mfrom: (1.1.7 upstream)
  • Revision ID: james.westby@ubuntu.com-20080627223434-0ib57vstn43bb4a3
Tags: 3.0.4.1-1
* Update of French, Russian and German translations. (closes: #488251)
* Added Bulgarian and Belarusian translations.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
[%# 1.0@bugzilla.org %]
2
 
[%# The contents of this file are subject to the Mozilla Public
3
 
  # License Version 1.1 (the "License"); you may not use this file
4
 
  # except in compliance with the License. You may obtain a copy of
5
 
  # the License at http://www.mozilla.org/MPL/
6
 
  #
7
 
  # Software distributed under the License is distributed on an "AS
8
 
  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
9
 
  # implied. See the License for the specific language governing
10
 
  # rights and limitations under the License.
11
 
  #
12
 
  # The Original Code is the Bugzilla Bug Tracking System.
13
 
  #
14
 
  # The Initial Developer of the Original Code is Netscape Communications
15
 
  # Corporation. Portions created by Netscape are
16
 
  # Copyright (C) 1998 Netscape Communications Corporation. All
17
 
  # Rights Reserved.
18
 
  #
19
 
  # Contributor(s): Terry Weissman <terry@mozilla.org>
20
 
  #                 Gervase Markham <gerv@gerv.net>
21
 
  #%]
22
 
 
23
 
[% PROCESS global/variables.none.tmpl %]
24
 
[% PROCESS "global/field-descs.none.tmpl" %]
25
 
[% INCLUDE global/header.html.tmpl title = "A $terms.Bug's Life Cycle" %]
26
 
 
27
 
<p>
28
 
The <b>status</b> and <b>resolution</b> fields define and track the life
29
 
cycle of [% terms.abug %].  
30
 
</p>
31
 
 
32
 
<a name="status"></a>
33
 
<a name="resolution"></a>
34
 
 
35
 
<table border="1" cellpadding="4">
36
 
  <tr align="center" valign="top">
37
 
    <td width="50%">
38
 
      <h1>STATUS</h1>
39
 
    </td>
40
 
 
41
 
    <td>
42
 
      <h1>RESOLUTION</h1>
43
 
    </td>
44
 
  </tr>
45
 
 
46
 
  <tr valign="top">
47
 
    <td>The <b>status</b> field indicates the general health of a 
48
 
    [% terms.bug %]. Only certain status transitions are allowed.</td>
49
 
 
50
 
    <td>The <b>resolution</b> field indicates what happened to this
51
 
    [%+ terms.bug %].</td>
52
 
  </tr>
53
 
 
54
 
  <tr valign="top">
55
 
    <td>
56
 
      <dl>
57
 
        <dt>
58
 
          <b>[% status_descs.UNCONFIRMED FILTER html %]</b>
59
 
        </dt>
60
 
        <dd>
61
 
          This [% terms.bug %] has recently been added to the database. 
62
 
          Nobody has validated that this [% terms.bug %] is true. Users
63
 
          who have the "canconfirm" permission set may confirm
64
 
          this [% terms.bug %], changing its state to [% status_descs.NEW FILTER html %]. Or, it may be
65
 
          directly resolved and marked [% status_descs.RESOLVED FILTER html %].
66
 
        </dd>
67
 
 
68
 
        <dt>
69
 
          <b>[% status_descs.NEW FILTER html %]</b>
70
 
        </dt>
71
 
        <dd>
72
 
          This [% terms.bug %] has recently been added to the assignee's
73
 
          list of [% terms.bugs %] and must be processed. [% terms.Bugs %] in
74
 
          this state may be accepted, and become <b>[% status_descs.ASSIGNED FILTER html %]</b>, passed
75
 
          on to someone else, and remain <b>[% status_descs.NEW FILTER html %]</b>, or resolved and marked
76
 
          <b>[% status_descs.RESOLVED FILTER html %]</b>.
77
 
        </dd>
78
 
 
79
 
        <dt>
80
 
          <b>[% status_descs.ASSIGNED FILTER html %]</b>
81
 
        </dt>
82
 
        <dd>
83
 
          This [% terms.bug %] is not yet resolved, but is assigned to the 
84
 
          proper person. From here [% terms.bugs %] can be given to another 
85
 
          person and become <b>[% status_descs.NEW FILTER html %]</b>, or resolved and become <b>[% status_descs.RESOLVED FILTER html  %]</b>.
86
 
        </dd>
87
 
 
88
 
        <dt>
89
 
          <b>[% status_descs.REOPENED FILTER html %]</b>
90
 
        </dt>
91
 
        <dd>
92
 
          This [% terms.bug %] was once resolved, but the resolution was 
93
 
          deemed incorrect. For example, a <b>[% get_resolution("WORKSFORME") FILTER html %]</b> [% terms.bug %] is
94
 
          <b>[% status_descs.REOPENED FILTER html %]</b> when more information shows up and
95
 
          the [% terms.bug %] is now reproducible. From here [% terms.bugs %] are
96
 
          either marked <b>[% status_descs.ASSIGNED FILTER html %]</b> or <b>[% status_descs.RESOLVED FILTER html %]</b>.
97
 
        </dd>
98
 
      </dl>
99
 
    </td>
100
 
 
101
 
    <td>
102
 
      <dl>
103
 
        <dd>
104
 
          No resolution yet. All [% terms.bugs %] which are in one of 
105
 
          these "open" states have the resolution set to blank. All 
106
 
          other [% terms.bugs %] will be marked with one of the following 
107
 
          resolutions.
108
 
        </dd>
109
 
      </dl>
110
 
    </td>
111
 
  </tr>
112
 
 
113
 
  <tr valign="top">
114
 
    <td>
115
 
      <dl>
116
 
        <dt>
117
 
          <b>[% status_descs.RESOLVED FILTER html %]</b>
118
 
        </dt>
119
 
        <dd>
120
 
          A resolution has been taken, and it is awaiting verification by
121
 
          QA. From here [% terms.bugs %] are either re-opened and become 
122
 
          <b>[% status_descs.REOPENED FILTER html %]</b>, are marked <b>[% status_descs.VERIFIED FILTER html %]</b>, or are closed for
123
 
          good and marked <b>[% status_descs.CLOSED FILTER html %]</b>.
124
 
        </dd>
125
 
 
126
 
        <dt>
127
 
          <b>[% status_descs.VERIFIED FILTER html %]</b>
128
 
        </dt>
129
 
        <dd>
130
 
          QA has looked at the [% terms.bug %] and the resolution and 
131
 
          agrees that the appropriate resolution has been taken. [% terms.Bugs %] remain
132
 
          in this state until the product they were reported
133
 
          against actually ships, at which point they become
134
 
          <b>[% status_descs.CLOSED FILTER html %]</b>.
135
 
        </dd>
136
 
 
137
 
        <dt>
138
 
          <b>[% status_descs.CLOSED FILTER html %]</b>
139
 
        </dt>
140
 
        <dd>
141
 
          The [% terms.bug %] is considered dead, the resolution is correct. 
142
 
          Any zombie [% terms.bugs %] who choose to walk the earth again must 
143
 
          do so by becoming <b>[% status_descs.REOPENED FILTER html %]</b>.
144
 
        </dd>
145
 
      </dl>
146
 
    </td>
147
 
 
148
 
    <td>
149
 
      <dl>
150
 
        <dt>
151
 
          <b>[% get_resolution("FIXED") FILTER html %]</b>
152
 
        </dt>
153
 
        <dd>
154
 
          A fix for this [% terms.bug %] is checked into the tree and 
155
 
          tested.
156
 
        </dd>
157
 
 
158
 
        <dt>
159
 
          <b>[% get_resolution("INVALID") FILTER html %]</b>
160
 
        </dt>
161
 
        <dd>
162
 
          The problem described is not [% terms.abug %].
163
 
        </dd>
164
 
 
165
 
        <dt>
166
 
          <b>[% get_resolution("WONTFIX") FILTER html %]</b>
167
 
        </dt>
168
 
        <dd>
169
 
          The problem described is [% terms.abug %] which will never be 
170
 
          fixed.
171
 
        </dd>
172
 
 
173
 
        <dt>
174
 
         <b>[% get_resolution("DUPLICATE") FILTER html %]</b>
175
 
        </dt>
176
 
        <dd>
177
 
          The problem is a duplicate of an existing [% terms.bug %].
178
 
          Marking [% terms.abug %] duplicate requires the [% terms.bug %]#
179
 
          of the duplicating [% terms.bug %] and will at least put
180
 
          that [% terms.bug %] number in the description field.
181
 
        </dd>
182
 
 
183
 
        <dt>
184
 
          <b>[% get_resolution("WORKSFORME") FILTER html %]</b>
185
 
        </dt>
186
 
        <dd>
187
 
          All attempts at reproducing this [% terms.bug %] were futile, 
188
 
          and reading the code produces no clues as to why the described
189
 
          behavior would occur. If more information appears later,
190
 
          the [% terms.bug %] can be reopened.
191
 
        </dd>
192
 
 
193
 
        <dt>
194
 
          <b>[% get_resolution("MOVED") FILTER html %]</b>
195
 
        </dt>
196
 
        <dd>
197
 
          The problem was specific to a related product 
198
 
          whose [% terms.bugs %] are tracked in
199
 
          another [% terms.bug %] database.
200
 
          The [% terms.bug %] has been moved to that database.
201
 
        </dd>
202
 
      </dl>
203
 
    </td>
204
 
  </tr>
205
 
</table>
206
 
 
207
 
<h2><a name="bug_severity">Severity</a></h2>
208
 
This field describes the impact of [% terms.abug %]. 
209
 
 
210
 
<table>
211
 
  <tr>
212
 
    <th>Blocker</th>
213
 
 
214
 
    <td>Blocks development and/or testing work</td>
215
 
  </tr>
216
 
 
217
 
  <tr>
218
 
    <th>Critical</th>
219
 
 
220
 
    <td>crashes, loss of data, severe memory leak</td>
221
 
  </tr>
222
 
 
223
 
  <tr>
224
 
    <th>Major</th>
225
 
 
226
 
    <td>major loss of function</td>
227
 
  </tr>
228
 
 
229
 
  <tr>
230
 
    <th>Normal</th>
231
 
 
232
 
    <td>regular issue, some loss of functionality under specific circumstances</td>
233
 
  </tr>
234
 
 
235
 
 
236
 
  <tr>
237
 
    <th>Minor</th>
238
 
 
239
 
    <td>minor loss of function, or other problem where easy
240
 
    workaround is present</td>
241
 
  </tr>
242
 
 
243
 
  <tr>
244
 
    <th>Trivial</th>
245
 
 
246
 
    <td>cosmetic problem like misspelled words or misaligned
247
 
    text</td>
248
 
  </tr>
249
 
 
250
 
  <tr>
251
 
    <th>Enhancement</th>
252
 
 
253
 
    <td>Request for enhancement</td>
254
 
</table>
255
 
 
256
 
<h2><a name="priority">Priority</a></h2>
257
 
This field describes the importance and order in which [% terms.abug %]
258
 
should be fixed. This field is utilized by the
259
 
programmers/engineers to prioritize their work to be done. The
260
 
available priorities range from <b>P1</b> (most important) to 
261
 
<b>P5</b> (least important). 
262
 
 
263
 
 
264
 
<h2><a name="rep_platform">Platform</a></h2>
265
 
This is the hardware platform against which the [% terms.bug %] was
266
 
reported. Legal platforms include: 
267
 
 
268
 
<ul>
269
 
  <li>All (happens on all platforms; cross-platform [% terms.bug %])</li>
270
 
 
271
 
  <li>Macintosh</li>
272
 
 
273
 
  <li>PC</li>
274
 
</ul>
275
 
<b>Note:</b> When searching, selecting the option "All" does not 
276
 
select [% terms.bugs %]
277
 
assigned against any platform. It merely selects [% terms.bugs %] that are
278
 
marked as occurring on all platforms, i.e. are designated "All". 
279
 
 
280
 
<h2><a name="op_sys">Operating System</a></h2>
281
 
This is the operating system against which the [% terms.bug %] was
282
 
reported. Legal operating systems include: 
283
 
 
284
 
<ul>
285
 
  <li>All (happens on all operating systems; cross-platform
286
 
  [% terms.bug %])</li>
287
 
 
288
 
  <li>Windows</li>
289
 
 
290
 
  <li>Mac OS</li>
291
 
 
292
 
  <li>Linux</li>
293
 
</ul>
294
 
Sometimes the operating system implies the platform, but not
295
 
always. For example, Linux can run on PC and Macintosh and
296
 
others. 
297
 
 
298
 
<h2><a name="assigned_to">Assigned To</a></h2>
299
 
 
300
 
<p>
301
 
This is the person in charge of resolving the [% terms.bug %]. Every time
302
 
this field changes, the status changes to <b>[% status_descs.NEW FILTER html %]</b> to make it
303
 
easy to see which new [% terms.bugs %] have appeared on a person's list.</p>
304
 
 
305
 
<p>
306
 
The default status for queries is set to [% status_descs.NEW FILTER html %], [% descs.bug_status_descs.ASSIGNED FILTER html %] and 
307
 
[% status_descs.REOPENED FILTER html %]. When searching for [% terms.bugs %] that have been resolved or
308
 
verified, remember to set the status field appropriately. 
309
 
</p>
310
 
 
311
 
[% INCLUDE global/footer.html.tmpl %]