diff options
Diffstat (limited to 'template/en/default/pages/fields.html.tmpl')
| -rw-r--r-- | template/en/default/pages/fields.html.tmpl | 64 |
1 files changed, 32 insertions, 32 deletions
diff --git a/template/en/default/pages/fields.html.tmpl b/template/en/default/pages/fields.html.tmpl index 7487841c8..9e938bbcb 100644 --- a/template/en/default/pages/fields.html.tmpl +++ b/template/en/default/pages/fields.html.tmpl @@ -54,47 +54,47 @@ cycle of [% terms.abug %]. <td> <dl> <dt> - <b>[% get_status("UNCONFIRMED") FILTER html %]</b> + <b>[% display_value("bug_status", "UNCONFIRMED") FILTER html %]</b> </dt> <dd> This [% terms.bug %] has recently been added to the database. Nobody has validated that this [% terms.bug %] is true. Users who have the "canconfirm" permission set may confirm - this [% terms.bug %], changing its state to [% get_status("NEW") FILTER html %]. Or, it may be - directly resolved and marked [% get_status("RESOLVED") FILTER html %]. + this [% terms.bug %], changing its state to [% display_value("bug_status", "NEW") FILTER html %]. Or, it may be + directly resolved and marked [% display_value("bug_status", "RESOLVED") FILTER html %]. </dd> <dt> - <b>[% get_status("NEW") FILTER html %]</b> + <b>[% display_value("bug_status", "NEW") FILTER html %]</b> </dt> <dd> This [% terms.bug %] has recently been added to the assignee's list of [% terms.bugs %] and must be processed. [% terms.Bugs %] in - this state may be accepted, and become <b>[% get_status("ASSIGNED") FILTER html %]</b>, passed - on to someone else, and remain <b>[% get_status("NEW") FILTER html %]</b>, or resolved and marked - <b>[% get_status("RESOLVED") FILTER html %]</b>. + this state may be accepted, and become <b>[% display_value("bug_status", "ASSIGNED") FILTER html %]</b>, passed + on to someone else, and remain <b>[% display_value("bug_status", "NEW") FILTER html %]</b>, or resolved and marked + <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>. </dd> <dt> - <b>[% get_status("ASSIGNED") FILTER html %]</b> + <b>[% display_value("bug_status", "ASSIGNED") FILTER html %]</b> </dt> <dd> This [% terms.bug %] is not yet resolved, but is assigned to the proper person. From here [% terms.bugs %] can be given to another - person and become <b>[% get_status("NEW") FILTER html %]</b>, or - resolved and become <b>[% get_status("RESOLVED") FILTER html %]</b>. + person and become <b>[% display_value("bug_status", "NEW") FILTER html %]</b>, or + resolved and become <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>. </dd> <dt> - <b>[% get_status("REOPENED") FILTER html %]</b> + <b>[% display_value("bug_status", "REOPENED") FILTER html %]</b> </dt> <dd> This [% terms.bug %] was once resolved, but the resolution was - deemed incorrect. For example, a <b>[% get_resolution("WORKSFORME") FILTER html %]</b> [% terms.bug %] is - <b>[% get_status("REOPENED") FILTER html %]</b> when more information shows up and + deemed incorrect. For example, a <b>[% display_value("resolution", "WORKSFORME") FILTER html %]</b> [% terms.bug %] is + <b>[% display_value("bug_status", "REOPENED") FILTER html %]</b> when more information shows up and the [% terms.bug %] is now reproducible. From here [% terms.bugs %] are - either marked <b>[% get_status("ASSIGNED") FILTER html %]</b> or - <b>[% get_status("RESOLVED") FILTER html %]</b>. + either marked <b>[% display_value("bug_status", "ASSIGNED") FILTER html %]</b> or + <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b>. </dd> </dl> </td> @@ -115,34 +115,34 @@ cycle of [% terms.abug %]. <td> <dl> <dt> - <b>[% get_status("RESOLVED") FILTER html %]</b> + <b>[% display_value("bug_status", "RESOLVED") FILTER html %]</b> </dt> <dd> A resolution has been taken, and it is awaiting verification by QA. From here [% terms.bugs %] are either re-opened and become - <b>[% get_status("REOPENED") FILTER html %]</b>, are marked - <b>[% get_status("VERIFIED") FILTER html %]</b>, or are closed for - good and marked <b>[% get_status("CLOSED") FILTER html %]</b>. + <b>[% display_value("bug_status", "REOPENED") FILTER html %]</b>, are marked + <b>[% display_value("bug_status", "VERIFIED") FILTER html %]</b>, or are closed for + good and marked <b>[% display_value("bug_status", "CLOSED") FILTER html %]</b>. </dd> <dt> - <b>[% get_status("VERIFIED") FILTER html %]</b> + <b>[% display_value("bug_status", "VERIFIED") FILTER html %]</b> </dt> <dd> QA has looked at the [% terms.bug %] and the resolution and agrees that the appropriate resolution has been taken. [% terms.Bugs %] remain in this state until the product they were reported against actually ships, at which point they become - <b>[% get_status("CLOSED") FILTER html %]</b>. + <b>[% display_value("bug_status", "CLOSED") FILTER html %]</b>. </dd> <dt> - <b>[% get_status("CLOSED") FILTER html %]</b> + <b>[% display_value("bug_status", "CLOSED") FILTER html %]</b> </dt> <dd> The [% terms.bug %] is considered dead, the resolution is correct. Any zombie [% terms.bugs %] who choose to walk the earth again must - do so by becoming <b>[% get_status("REOPENED") FILTER html %]</b>. + do so by becoming <b>[% display_value("bug_status", "REOPENED") FILTER html %]</b>. </dd> </dl> </td> @@ -150,7 +150,7 @@ cycle of [% terms.abug %]. <td> <dl> <dt> - <b>[% get_resolution("FIXED") FILTER html %]</b> + <b>[% display_value("resolution", "FIXED") FILTER html %]</b> </dt> <dd> A fix for this [% terms.bug %] is checked into the tree and @@ -158,14 +158,14 @@ cycle of [% terms.abug %]. </dd> <dt> - <b>[% get_resolution("INVALID") FILTER html %]</b> + <b>[% display_value("resolution", "INVALID") FILTER html %]</b> </dt> <dd> The problem described is not [% terms.abug %]. </dd> <dt> - <b>[% get_resolution("WONTFIX") FILTER html %]</b> + <b>[% display_value("resolution", "WONTFIX") FILTER html %]</b> </dt> <dd> The problem described is [% terms.abug %] which will never be @@ -173,7 +173,7 @@ cycle of [% terms.abug %]. </dd> <dt> - <b>[% get_resolution("DUPLICATE") FILTER html %]</b> + <b>[% display_value("resolution", "DUPLICATE") FILTER html %]</b> </dt> <dd> The problem is a duplicate of an existing [% terms.bug %]. @@ -183,7 +183,7 @@ cycle of [% terms.abug %]. </dd> <dt> - <b>[% get_resolution("WORKSFORME") FILTER html %]</b> + <b>[% display_value("resolution", "WORKSFORME") FILTER html %]</b> </dt> <dd> All attempts at reproducing this [% terms.bug %] were futile, @@ -193,7 +193,7 @@ cycle of [% terms.abug %]. </dd> <dt> - <b>[% get_resolution("MOVED") FILTER html %]</b> + <b>[% display_value("resolution", "MOVED") FILTER html %]</b> </dt> <dd> The problem was specific to a related product @@ -303,12 +303,12 @@ others. <p> This is the person in charge of resolving the [% terms.bug %]. Every time -this field changes, the status changes to <b>[% get_status("NEW") FILTER html %]</b> to make it +this field changes, the status changes to <b>[% display_value("bug_status", "NEW") FILTER html %]</b> to make it easy to see which new [% terms.bugs %] have appeared on a person's list.</p> <p> -The default status for queries is set to [% get_status("NEW") FILTER html %], -[%+ get_status("ASSIGNED") FILTER html %] and [% get_status("REOPENED") FILTER html %]. +The default status for queries is set to [% display_value("bug_status", "NEW") FILTER html %], +[%+ display_value("bug_status", "ASSIGNED") FILTER html %] and [% display_value("bug_status", "REOPENED") FILTER html %]. When searching for [% terms.bugs %] that have been resolved or verified, remember to set the status field appropriately. </p> |