Changes between Version 9 and Version 10 of QueuesPlugin


Ignore:
Timestamp:
Jan 4, 2011, 4:26:29 AM (13 years ago)
Author:
Rob Guttman
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • QueuesPlugin

    v9 v10  
    8484Notice that the first column is the {{{position}}} custom field and is defined as {{{p.value as position}}} - this is ''required''.  The first column's name must always match the name of the custom field used to maintain the queue position.  (You can name them whatever you want; they just have to match.)  In the ORDER BY clause, we cast the position field to an integer.  This example is for sqlite3; you'll need to check the syntax for the database you're using.  If your database does not support casting, you can use position padding option described below.  There are no other restrictions to the SQL you use for your reports (as far as I'm aware!).
    8585
    86 If the report above was created as, say, report {{{9}}}, then you would need to add it to the {{{[queues]}}} section of the {{{{trac.ini}}} file:
     86If the report above was created as, say, report {{{9}}}, then you would need to add it to the {{{[queues]}}} section of the {{{trac.ini}}} file:
    8787{{{
    8888[queues]
    … …  
    9797
    9898=== Team work queue per milestone ===
    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:
     99To 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:
    100100{{{
    101101SELECT s.value AS __color__,
    … …  
    149149}}}
    150150
    151 In addition to the updating {{{trac.ini}}} with the new report number, you now also need to describe what operation the plugin should take for each group as follows:
     151In addition to the updating {{{trac.ini}}} with the new report number, you now also need to describe what operation the plugin should take for each group:
    152152{{{
    153153[queues]
    … …  
    156156}}}
    157157
    158 The {{{group.triage = clear}}} tells the plugin that the {{{Triage}}} group shouldn't reorder positions (the default operation).  The name {{{Triage}}} is just an example - you can use any name as long as you make the config match the name used in the SQL statement.  Here's the screenshot of the report:
     158The {{{group.triage = clear}}} tells the plugin that the {{{Triage}}} group shouldn't reorder positions (reordering is the default operation).  The group name {{{Triage}}} is just an example - you can use any name as long as you make the config match it.  Here's the screenshot of the report:
    159159
    160160[[Image(example2.png)]]
    161161
    162 The tickets are now grouped with the Triage group at the top.  You can drag-and-drop tickets from the {{{Triage}}} group to anywhere in the {{{milestone1}}} group.  Furthermore, you can also clear the position from any ticket by moving it from the {{{milestone1}}} group to anywhere in the {{{Triage}}} group (hence the full meaning the the {{{clear}}} operation described above).  If you don't want to see the tickets The full list of operation directives are:
    163 
    164  * reorder (the default)
    165  * clear
    166  * ignore
    167 
    168 There should only be one {{{reorder}}} group but any number of clear and ignore groups.  The {{{ignore}}} operation will simply list the tickets that match your grouping but tickets can't be moved out of or into it.  This is useful, for example, if you want to show work in the queue that has been implemented but still in a {{{verifying}}} state and not yet closed.  The SQL syntax is left as an exercise to the reader.  :)  TIP: You can click on any {{{clear}}} or {{{ignore}}} group heading to toggle between hiding and showing its contents.
     162The tickets are now grouped with the Triage group at the top.  You can drag-and-drop tickets from the {{{Triage}}} group to anywhere in the {{{milestone1}}} group.  Furthermore, you can also clear the position from any ticket by dragging-and-dropping it from the {{{milestone1}}} group to anywhere in the {{{Triage}}} group (hence the full meaning of the {{{clear}}} operation described above).  (Note that currently a group must have at least one ticket in it to be able to drag-and-drop tickets into it.)  The full list of operation directives are:
     163
     164 * {{{reorder}}} (the default)
     165 * {{{clear}}}
     166 * {{{ignore}}}
     167
     168There must be only one {{{reorder}}} group per report but you can have any number of clear and ignore groups.  The {{{ignore}}} operation will simply list the tickets that match your grouping but tickets can't be moved out of or into it.  This is useful, for example, if you want to show work in the queue that has been implemented but still in, say, a {{{verifying}}} state and not yet closed.  The SQL syntax is left as an exercise to the reader.  :)
     169
     170TIP: You can click on any {{{clear}}} or {{{ignore}}} group heading to toggle between hiding and showing its tickets.
    169171
    170172=== Team work queue per custom field ===
    171 Another use case is when you want to retain the use of milestones as an orthogonal date-based means to manage projects and use a separate custom field to 'bucket' tickets into queues.  For example:
     173Another 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:
    172174{{{
    173175[ticket-custom]
    … …  
    177179}}}
    178180
    179 You can simply re-write your SQL query to pivot on a {{{QUEUE}}} dynamic variable instead of (or perhaps in addition to) a {{{MILESTONE}}} dynamic variable.  The important thing is that the {{{position}}} custom field should be used for one and only one queue.
     181You can simply re-write your SQL query to pivot on a {{{QUEUE}}} dynamic variable, in this example, instead of (or perhaps in addition to) a {{{MILESTONE}}} dynamic variable.  The important thing is that the {{{position}}} custom field must only be used for one and only one queue.
    180182
    181183=== Personal work queue ===
    182 It should be clear now that you can create a queue for just about any SQL query as long as the {{{position}}} custom field is used for one and only one queue.  Another use case is if you want to use queues simply to let users manage their own work load.  You can simply create a report that pivots on the special, built-in {{{$USER}}} dynamic variable.  Viola!  Personal work queues for everyone using a single report.
     184It should be clear by now that you can create a queue for just about any SQL report as long as the {{{position}}} custom field is used for one and only one queue.  Another use case is if you want to use queues simply to let users manage their own work load.  You can simply create a report that pivots on the special, built-in {{{$USER}}} dynamic variable.  Viola!  Personal work queues for everyone using a single report.
    183185
    184186=== Team work queue ''and'' personal work queue ===
    185 What if you wanted to 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 purpose.  The answer?  Create a second custom field to manage the personal work queue's position:
     187What 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:
    186188{{{
    187189[ticket-custom]
    … …  
    192194}}}
    193195
    194 Now you can use the {{{position}}} field as before in the team work queues and the {{{myposition}}} field in the personal work queues using all of the techniques described above.  So for instance, the personal work queue in this case may define the first column as {{{p.value as "My Position"}}}.  Any uppercase letters are converted to lowercase and any spaces are removed in order to determine the correct field name.
     196Now you can use the {{{position}}} field as before for the team work queues and the {{{myposition}}} field for the personal work queues using all of the techniques described above.  So for instance, the personal work queue in this case may define the first column as {{{p.value as "My Position"}}}.  Any uppercase letters are converted to lowercase and any spaces are removed in order to determine the correct field name.
    195197
    196198=== Development work queue ''and'' Product Management work queue ===
    197 The same principle described above for supporting team and personal work queues simultaneously can be used to enable work queues for multiple stakeholders by using separate {{{position}}} fields.  So for example, Product Management may want to express their preferred order of work (beyond what a {{{priority}}} field permits) while the development team can creates report that shows Product Management's preferred ordering alongside their own ordering.
    198 
    199 Hopefully it's clear that many variants of this use case are also possible.
     199The same principle described above for simultaneously supporting team and personal work queues can be used to enable work queues for multiple stakeholders by using separate {{{position}}} fields.  So for example, Product Management may want to express their preferred order of work (beyond what a {{{priority}}} field permits) while the development team can use a report/queue that shows Product Management's preferred ordering alongside their own ordering.
     200
     201Hopefully it's clear that many variants of this use case are possible.
    200202
    201203
    202204== Tips / Options ==
    203205=== Position padding ===
    204 Whether or not you cast the {{position}}} field into an integer for report ordering, you still may want to pad your position numbers so that they sort correctly in any report or custom query in which they appear.  You set this up globally in {{{trac.ini}}}:
     206Whether or not you cast the {{{position}}} field into an integer for report ordering, you still may want to pad your position numbers so that they sort correctly in any report or custom query in which they appear.  You set this up globally in {{{trac.ini}}}:
    205207{{{
    206208[queues]
    … …  
    217219}}}
    218220
    219 A {{{max_position}}} of {{{99}}} is the default.  This means that positions 100 and beyond will get set to position {{{99}} whenever they appear in a queue.
     221A {{{max_position}}} of {{{99}}} is the default.  This means that positions 100 and beyond will get set to position {{{99}}} whenever they appear in a queue.
    220222
    221223=== "Max items per page" ===
    222 Trac automatically paginates reports longer 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}}}:
     224Trac 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}}}:
    223225{{{
    224226[report]
    … …  
    226228}}}
    227229
    228 .. or bookmark reports setting {{{max=N}}} as desired.  For example, seeing a long queue can be overwhelming or intimidating to some, so you may want to encourage them to only look at the first 10 or 20 using this param/argument.  However, note that queue reordering only works on the first page (it's disabled for subsequent pages).  So if you need to reorder items on the second or third pages, increase the "Max items per page" argument as needed.
     230.. or bookmark the report queue with a {{{max=N}}} argument as desired.  For example, seeing a long queue can be overwhelming or intimidating to some, so you may want to encourage the team to only look at the first 10 or 20 tickets using this argument.  However, note that queue reordering only works on the first page of a report queue (it's disabled for subsequent pages).  So if you need to reorder items on the second or third page, increase the "Max items per page" argument as needed.
    229231
    230232=== Enhanced user experience ===
    231 Depending on how you use work queues, several complementary plugins may be beneficial to you:
     233Depending on how you use work queues, several complementary plugins may enhance the user experience:
    232234
    233235 * DynamicVariablesPlugin - as described above, this converts dynamic variable textboxes into dropdown menus for those fields which are select fields.  This can make navigating amongst queues much easier.
    234  * DynamicFieldsPlugin - allows you to clear the {{{position}}} field when the queue changes, for example, and hide the {{{myposition}}} field from general view - as just examples of how it can enhance the user experience of this queues plugin.
    235  * HideChangesPlugin - can hide ticket changes that do not have comments thus reducing the noise from queue reordering changes.  See next section for other options.
     236 * DynamicFieldsPlugin - allows you to clear the {{{position}}} field when the queue changes and hide the {{{myposition}}} field from general view.  These are just small examples of how the plugin can enhance the user experience of this queues plugin.
     237 * HideChangesPlugin - can hide ticket changes that do not have comments thus reducing the noise from queue reordering changes.  See the next audit section for other options.
    236238
    237239=== Auditing ticket reorderings ===
    238 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 provides several different methods to audit queue reorderings that gets set in {{{trac.ini}}} as follows:
     240Changing 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}}}:
    239241{{{
    240242[queues]
    … …  
    242244}}}
    243245
    244 There are three valid values to the {{{audit}}} option:
    245  * {{{ticket}}} - normal ticket changes
    246  * {{{log}}} (default) - gets written to log file only (if enabled in {{{logging}}} sectipn)
     246There are three valid values for the {{{audit}}} option:
     247 * {{{ticket}}} - changes get written normally to tickets
     248 * {{{log}}} (default) - changes get written to log (if/as enabled in the {{{[logging]}}} section)
    247249 * {{{none}}} - no auditing at all
    248250