https://rt-wiki.bestpractical.com/index.php?action=history&feed=atom&title=PriorityPriority - Revision history2026-08-21T21:58:13ZRevision history for this page on the wikiMediaWiki 1.41.1https://rt-wiki.bestpractical.com/index.php?title=Priority&diff=2645&oldid=prevAdmin: 3 revisions imported2016-04-06T20:20:29Z<p>3 revisions imported</p>
<table style="background-color: #fff; color: #202122;" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 16:20, 6 April 2016</td>
</tr><tr><td colspan="4" class="diff-notice" lang="en"><div class="mw-diff-empty">(No difference)</div>
</td></tr>
<!-- diff cache key bestpractical_mediawiki1459887241:diff:1.41:old-2644:rev-2645 -->
</table>Adminhttps://rt-wiki.bestpractical.com/index.php?title=Priority&diff=2644&oldid=prev104.129.79.1: type2014-09-25T21:34:00Z<p>type</p>
<p><b>New page</b></p><div>The '''Priority''' of a [[Ticket]] in RT is a number between 0 and 100 that is designed to express the relative urgency of resolving the ticket. Besides a priority, every ticket can have a [[FinalPriority]] that can be different from the actual current priority. [[PriorityEscalation]] can be used to change the priority daily until it reaches the FinalPriority at the [[DueDate]].<br />
<br />
Both the Priority and the FinalPriority are set upon creation of a new ticket to values that are specified in the [[QueueProperties]].<br />
<br />
== Example priority scale ==<br />
<br />
In an organization that uses multiple queues, it is often useful to use a common priority scale for all tickets. One possibility is:<br />
<br />
* Priorities 11-20 : A minor inconvenience. There is a good workaround<br />
* Priorities 21-30 : An inconvenience. There is a workaround<br />
* Priorities 31-40 : A major inconvenience. There is a troubling workaround<br />
* Priorities 41-50 : A real problem. Someone can not do part of his work until this is resolved.<br />
* Priorities 51-60 : A disaster. Someone can not work at all until this is resolved.<br />
<br />
Other schemas are equally good. This is only given as an example and it is '''NOT''' logically consistent with [[PriorityEscalation]].<br />
<br />
== Related issues ==<br />
<br />
See also [[SeverityCodes]], which includes some discussion of more subtle uses of and inputs to Priority. It is common in other ticketing systems to have multiple fields for simpler values such as scope and severity of impact, SLA parameters, etc. which can all be used as inputs to a simple numeric Priority value used to schedule work (i.e. to work on the highest Priority first.) In RT, it is common to use a custom field to describe problem severity because that allows the use of the built-in (but by default inactive) [[PriorityEscalation]] system.<br />
<br />
== Labelled Priority Patch ==<br />
<br />
This patch (http://www.parliant.com/~cmh/rt/) replaces the numeric priority display throughout RT by labelled equivalents. The administrator defines the mapping between numeric priorities and labels. Internally RT continues to use numeric priorities, but when they are displayed to the user the labels are used instead.<br />
<br />
== RT-Extension-PriorityAsString ==<br />
<br />
Similar to the above patch, but packaged as an RT extension. Only usable with newer versions of RT 3.8 http://search.cpan.org/dist/RT-Extension-PriorityAsString/<br />
<br />
---<br />
<br />
See also [[X-Priority]]</div>104.129.79.1