Changes between Version 29 and Version 30 of QueuesPlugin
- Timestamp:
- Mar 17, 2014, 10:56:24 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
QueuesPlugin
v29 v30 12 12 == Configuration == 13 13 1. Install the plugin (after downloading and unzipping): 14 {{{15 16 17 18 19 20 14 {{{#!sh 15 cd queuesplugin/0.12 16 sudo python setup.py bdist_egg 17 sudo cp dist/TracQueues*.egg /your/trac/location/plugins/ 18 }}} 19 20 See [http://trac.edgewall.org/wiki/TracPlugins TracPlugins] for more installation details and options. You'll likely need to restart Trac's web server after installation. 21 21 22 22 2. Enable the plugin: 23 {{{24 25 26 27 28 23 {{{#!ini 24 [components] 25 queues.* = enabled 26 }}} 27 28 You can alternatively use the Trac Web Admin GUI to enable any or all rules. 29 29 30 30 3. Create a custom field to contain the position information - example {{{trac.ini}}} config: 31 {{{32 33 34 31 {{{#!ini 32 [ticket-custom] 33 position = text 34 }}} 35 35 36 36 4. Create/modify reports to be used as ticket queues whose first column's name must match the (custom) field created in step 3 above: 37 38 37 * Can contain uppercase characters (which will get converted to lowercase) 38 * Can use spaces (which will get removed) 39 39 40 40 5. Tell the queues plugin which reports to convert to queues - example {{{trac.ini}}} config: 41 {{{42 43 44 41 {{{#!ini 42 [queues] 43 reports = 13,14 44 }}} 45 45 46 46 See the [wiki:QueuesPlugin#Examples examples below] for more detailed configuration examples, options and capabilities. … … 68 68 === Team work queue for all tickets === 69 69 The simplest example is a queue of all tickets. Assuming you already created a new custom {{{position}}} field as described [wiki:QueuesPlugin#Configuration above], you can create a new report like this: 70 {{{ 70 {{{#!sql 71 71 SELECT s.value AS __color__, 72 72 p.value as position, t.id AS ticket, summary, … … 85 85 86 86 If the report above was created as, say, report {{{13}}}, then you would need to add it to the {{{[queues]}}} section of the {{{trac.ini}}} file: 87 {{{ 87 {{{#!ini 88 88 [queues] 89 89 reports = 13 … … 98 98 === Team work queue per milestone === 99 99 To order your work queue within a milestone, you could create a single report that uses a {{{$MILESTONE}}} [http://trac.edgewall.org/wiki/TracReports#AdvancedReports:DynamicVariables report dynamic variable] to set the milestone field: 100 {{{ 100 {{{#!sql 101 101 SELECT s.value AS __color__, 102 102 p.value as position, t.id AS ticket, summary, … … 113 113 114 114 If this was created as report {{{14}}}, update the {{{trac.ini}}} file as so (and restart your web server if needed): 115 {{{ 115 {{{#!ini 116 116 [queues] 117 117 reports = 13,14 … … 126 126 === Team work queue per milestone with a Triage group === 127 127 The problem with the above example is that new tickets without a {{{position}}} field will get ordered above your other tickets. This may not always be what you want. So instead you can group the tickets into those with a position and those without and then individually drag-and-drop the new tickets into the ordered queue at your leisure. Here's what the report could look like: 128 {{{ 128 {{{#!sql 129 129 SELECT s.value AS __color__, 130 130 (CASE p.value … … 150 150 151 151 In addition to updating {{{trac.ini}}} with the new report number, you now also need to describe what operation the plugin should take for each group: 152 {{{ 152 {{{#!ini 153 153 [queues] 154 154 reports = 13,14,15 … … 172 172 === Team work queue per custom field === 173 173 Another use case is when you want to retain the use of milestones as an orthogonal, date-based means to manage work and use a separate custom field to define queues. For example: 174 {{{ 174 {{{#!ini 175 175 [ticket-custom] 176 176 position = text … … 186 186 === Team work queue ''and'' personal work queue === 187 187 What if you wanted both a team work queue that pivoted on, say, a custom {{{queue}}} field and personal work queues as described above. We can't reuse the same {{{position}}} field for each queue. The answer? Create a second custom field to manage the personal work queue's position: 188 {{{ 188 {{{#!ini 189 189 [ticket-custom] 190 190 position = text … … 205 205 === Position padding === 206 206 Whether or not you cast the {{{position}}} field into an integer for report ordering, you still may want to pad your position numbers with leading {{{0}}}s so that they sort correctly in any report or custom query in which they appear. You set this up globally in {{{trac.ini}}}: 207 {{{ 207 {{{#!ini 208 208 [queues] 209 209 pad_length = 2 … … 214 214 === Maximum position === 215 215 Typically, the further down a queue you go, the less accurate the ordering becomes. This is natural. Which means that after a point, ordering doesn't really matter anymore. One way to help reinforce this is by defining a {{{max_position}}} value: 216 {{{ 216 {{{#!ini 217 217 [queues] 218 218 max_position = 99 … … 223 223 === "Max items per page" === 224 224 Trac automatically paginates reports that contain more tickets than the defined "Max items per page". Depending on your usage of queues, you may want to either set this value lower (or higher) globally for all reports in {{{trac.ini}}}: 225 {{{ 225 {{{#!ini 226 226 [report] 227 227 items_per_page = 100 … … 240 240 === Auditing ticket reorderings === 241 241 Changing the value of custom fields would normally cause a ticket change which would show up on the ticket. This may be just what you want to audit queue reorderings, however it can be quite noisy. So this plugin allows you to select from several different methods to audit queue reorderings in {{{trac.ini}}}: 242 {{{ 242 {{{#!ini 243 243 [queues] 244 244 audit = log