Changes between Version 29 and Version 30 of QueuesPlugin

Mar 17, 2014, 10:56:24 PM (4 years ago)
Ryan J Ollos

Code block highlighting.


  • QueuesPlugin

    v29 v30  
    1212== Configuration ==
    1313 1. Install the plugin (after downloading and unzipping):
    14     {{{
    15     cd queuesplugin/0.12
    16     sudo python bdist_egg
    17     sudo cp dist/TracQueues*.egg /your/trac/location/plugins/
    18     }}}
    20     See [ TracPlugins] for more installation details and options.  You'll likely need to restart Trac's web server after installation.
     14 {{{#!sh
     15cd queuesplugin/0.12
     16sudo python bdist_egg
     17sudo cp dist/TracQueues*.egg /your/trac/location/plugins/
     20 See [ TracPlugins] for more installation details and options.  You'll likely need to restart Trac's web server after installation.
    2222 2. Enable the plugin:
    23     {{{
    24     [components]
    25     queues.* = enabled
    26     }}}
    28     You can alternatively use the Trac Web Admin GUI to enable any or all rules.
     23 {{{#!ini
     25queues.* = enabled
     28 You can alternatively use the Trac Web Admin GUI to enable any or all rules.
    3030 3. Create a custom field to contain the position information - example {{{trac.ini}}} config:
    31     {{{
    32     [ticket-custom]
    33     position = text
    34     }}}
     31 {{{#!ini
     33position = text
    3636 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      * Can contain uppercase characters (which will get converted to lowercase)
    38      * Can use spaces (which will get removed)
     37  * Can contain uppercase characters (which will get converted to lowercase)
     38  * Can use spaces (which will get removed)
    4040 5. Tell the queues plugin which reports to convert to queues - example {{{trac.ini}}} config:
    41     {{{
    42     [queues]
    43     reports = 13,14
    44     }}}
     41 {{{#!ini
     43reports = 13,14
    4646See the [wiki:QueuesPlugin#Examples examples below] for more detailed configuration examples, options and capabilities.
    6868=== Team work queue for all tickets ===
    6969The 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 {{{
    7171SELECT s.value AS __color__,
    7272       p.value as position, AS ticket, summary,
    8686If 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 {{{
    8989reports = 13
    9898=== Team work queue per milestone ===
    9999To order your work queue within a milestone, you could create a single report that uses a {{{$MILESTONE}}} [ report dynamic variable] to set the milestone field:
    100 {{{
    101101SELECT s.value AS __color__,
    102102       p.value as position, AS ticket, summary,
    114114If this was created as report {{{14}}}, update the {{{trac.ini}}} file as so (and restart your web server if needed):
    115 {{{
    117117reports = 13,14
    126126=== Team work queue per milestone with a Triage group ===
    127127The 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 {{{
    129129SELECT s.value AS __color__,
    130130          (CASE p.value
    151151In 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 {{{
    154154reports = 13,14,15
    172172=== Team work queue per custom field ===
    173173Another 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 {{{
    176176position = text
    186186=== Team work queue ''and'' personal work queue ===
    187187What 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 {{{
    190190position = text
    205205=== Position padding ===
    206206Whether 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 {{{
    209209pad_length = 2
    214214=== Maximum position ===
    215215Typically, 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 {{{
    218218max_position = 99
    223223=== "Max items per page" ===
    224224Trac 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 {{{
    227227items_per_page = 100
    240240=== Auditing ticket reorderings ===
    241241Changing 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 {{{
    244244audit = log