| 247 | | == some ideas for next steps == |
| 248 | | |
| 249 | | New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component. If desired, add a single-line link to that ticket here. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations. |
| 250 | | |
| 251 | | If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket. |
| 252 | | |
| 253 | | * the "operation" could be on the nodes, possible operations are: |
| 254 | | * '''preops''': automatic, before entering the state/activity |
| 255 | | * '''postops''': automatic, when leaving the state/activity |
| 256 | | * '''actions''': can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows. |
| 257 | | ''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.'' |
| 258 | | |
| 259 | | * operations could be anything: sum up the time used for the activity, or just write some statistical fields like |
| 260 | | ''A workflow plugin can add an arbitrary workflow operation, so this is already possible.'' |
| 261 | | |
| 262 | | * set_actor should be an operation allowing to set the owner, e.g. as a "preop": |
| 263 | | * either to a role, a person |
| 264 | | * entered fix at define time, or at run time, e.g. out of a field, or select. |
| 265 | | ''This is either duplicating the existing `set_owner` operation, or needs to be clarified.'' |
| 266 | | |
| 267 | | * Actions should be selectable based on the ticket type (different Workflows for different tickets) |
| 268 | | ''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.'' |
| 269 | | |
| 270 | | * I'd wish to have an option to perform automatic status changes. In my case, I do not want to start with "new", but with "assigned". So tickets in state "new" should automatically go into state "assigned". Or is there already a way to do this and I just missed it? |
| 271 | | ''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]'' |
| 272 | | |
| 273 | | * I added a 'testing' state. A tester can close the ticket or reject it. I'd like the transition from testing to rejected to set the owner to the person that put the ticket in 'testing'. The [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] is close with set_owner_to_field, but we need something like set_field_to_owner. |
| 274 | | |
| 275 | | ''See for example [wiki:TracDev/PluginDevelopment/ExtensionPoints/trac.ticket.api.ITicketChangeListener ITicketChangeListener]. This will allow you to write a plugin that will suit your needs.'' |
| 276 | | |
| 277 | | * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state. |
| 278 | | |
| 279 | | ''You could do a query on the ticket table and the ticket changes table and find out transitions between individual states and the time the ticket had been in each of the available states.'' |
| | 247 | == Ideas for next steps == |
| | 248 | |
| | 249 | Enhancement ideas for the workflow system should be filed as enhancement tickets against the [trac:query:?status=assigned&status=new&status=reopened&keywords=~workflow&component=ticket+system ticket system] component. You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page. Also look at the [th:AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations. |
