Changes between Version 19 and Version 20 of TracWorkflow

Timestamp:

May 8, 2008, 4:46:45 AM (16 years ago)

Author:

Eli Carter

Comment:

—

TracWorkflow

@@ -134 +134 @@
 == some ideas for next steps ==
 
-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.
+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 [th:wiki:AdvancedTicketWorkflowPlugin] as it provides experimental operations.
 
 If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.
@@ -142 +142 @@
    * '''postops''': automatic, when leaving the state/activity
    * '''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.
-This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.
+''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.''
 
  * operations could be anything: sum up the time used for the activity, or just write some statistical fields like 
-A workflow plugin can add an arbitrary workflow operation, so this is already possible.
+''A workflow plugin can add an arbitrary workflow operation, so this is already possible.''
 
  * set_actor should be an operation allowing to set the owner, e.g. as a "preop":
    * either to a role, a person
    * entered fix at define time, or at run time, e.g. out of a field, or select.
-This is either duplicating the existing `set_owner` operation, or needs to be clarified.
+''This is either duplicating the existing `set_owner` operation, or needs to be clarified.''
 
  * Actions should be selectable based on the ticket type (different Workflows for different tickets)
-This is becoming a frequent request, with clear usecases.  The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point.
+''This is becoming a frequent request, with clear usecases.  The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point.''