@@ -134,44 +137,46 @@ be in one of the following:
When an action with child workflows is enabled, we start the child cases defined by the parent workflow, executing the initial action on each of them.
We create one case per role in workflow_action_children times one case per member/user for roles with a mapping_type of -'per_member'/'per_user'. If more than one role has a mapping_type -other than 'per_role', we will create cases for the cartesian -product of members/users of those roles in the parent workflow.
+'per_member'/'per_user'. If more than one role has +a mapping_type other than 'per_role', we will create cases +for the cartesian product of members/users of those roles in the +parent workflow.The action can be triggered by a timeout, by the user, by child cases reaching a certain state, or by all child cases being completed.
-An example of "child cases reaching a certain state" would be -the TIP voting process, where 2/3rd Approved votes is enough to -determine the outcome, and we don't need the rest to vote -anymore.
-When triggered, all child cases with a case_state of 'active' -are put into the 'canceled' state. All child cases have their -'locked_p' flag set to true, so they cannot be reopened.
+An example of "child cases reaching a certain state" +would be the TIP voting process, where 2/3rd Approved votes is +enough to determine the outcome, and we don't need the rest to +vote anymore.
+When triggered, all child cases with a case_state of +'active' are put into the 'canceled' state. All +child cases have their 'locked_p' flag set to true, so they +cannot be reopened.
@@ -265,15 +270,16 @@
- case::enabled_actions -case_id
-
- Find the case state (open)
- Find the actions enabled in this state (ask client, abort)
- "abort" is final, put it on the list.
- "ask client" has a child; look in workflow_enabled_actions for -the state
- If there's no row in enabled actions for "ask client", execute -"ac-init", which will set case_enabled_actions.state_id to -ac-asking for case_id #1 and action_id "ask client".
- Look in case_enabled_actions.state_id for case_id #1 and +
- Find the case state (open)
- Find the actions enabled in this state (ask client, abort)
- "abort" is final, put it on the list.
- "ask client" has a child; look in +workflow_enabled_actions for the state
- If there's no row in enabled actions for "ask +client", execute "ac-init", which will set +case_enabled_actions.state_id to ac-asking for case_id #1 and +action_id "ask client".
- Look in case_enabled_actions.state_id for case_id #1 and action_id "ask client" for the substate (ac-asking).
- Find the enabled actions in the ac-asking state (ac-ask).
- ac-ask is final, put it on the list
- case::action::execute -case_id -action_id
-
- The question is which state to change.
- Find the action's parent_action_id
- If null, then change cases.state_id
- Otherwise, change case_enabled_actions.state_id.
+- The question is which state to change.
- Find the action's parent_action_id
- If null, then change cases.state_id
- Otherwise, change case_enabled_actions.state_id.
- Which roles are assigned/allowed to perform an action? Unchanged from current design.
- Which roles do a user play? Unchanged from current design.
- What is the activity history on this case? Unchanged from @@ -287,8 +293,8 @@
- Keeping the sub-state in the workflow_case_enabled_actions table.
- Kill the completed rows in workflow_case_enabled_actions, move -stuff into the case-log instead => that's going to be much, much -better for performance.
+stuff into the case-log instead => that's going to be much, +much better for performance.Design 2, Parallel Actions
Example II: Parallel
@@ -340,7 +346,8 @@
Difference between parallel sub-actions and non-parallel -sub-actions: If they are parallel, we enable all of them and don't -maintain state there; if they're not, we look for an init-action, -and do maintain state.
+sub-actions: If they are parallel, we enable all of them and +don't maintain state there; if they're not, we look for an +init-action, and do maintain state.
actions action_id | parent_action_id | assigned_role | trigger_type | new_state
(workflow) ----------------+------------------+---------------+--------------+---------------
@@ -384,12 +391,12 @@
opi-init | opinion-wr | lawyer | init | opi-open
opinion | opinion-wr | lawyer | user | opi-done
-An action with type 'workflow' will maintain state inside -itself.
-Can we do away with the extra layer of 'workflow' inside the -'parallel' track? How do we know that the child workflow has been -completed -- i guess we do, because we keep the state until its -parent is gone...
+An action with type 'workflow' will maintain state +inside itself.
+Can we do away with the extra layer of 'workflow' inside +the 'parallel' track? How do we know that the child +workflow has been completed -- i guess we do, because we keep the +state until its parent is gone...
actions action_id | parent_action_id | assigned_role | trigger_type | new_state
(parallel-simple) ----------------+------------------+---------------+--------------+---------------
@@ -415,12 +422,12 @@
#3 | opinion | #1 | yes | no
-Simple: We'd have to keep the row in case_enabled_actions around -with completed_p = yes until the parent action is also complete. -When an action is completed, it deletes the rows for all its -children. If the action does not have a parent action, we delete -the row (thus we don't keep completed_p rows around for top-level -actions).
+Simple: We'd have to keep the row in case_enabled_actions +around with completed_p = yes until the parent action is also +complete. When an action is completed, it deletes the rows for all +its children. If the action does not have a parent action, we +delete the row (thus we don't keep completed_p rows around for +top-level actions).
@@ -508,9 +515,10 @@
always_enabled_p ---------------- -- if parent_action_id is null, it means it's always enabled +- if parent_action_id is null, it means it's always enabled -- if parent action is trigger_type workflow, it means it's enabled when its parent workflow is enabled. +- if parent action is trigger_type workflow, it means it's enabled when its parent workflow is enabled. -> ::enable it after starting the workflow, i.e. executing the initial action -> will it stay enabled? -> it will get disabled automatically by cascading delete when its parent is deleted -- if parent action is trigger_type parallel, it has no meaning, all the parent's children will get enabled, anyway +- if parent action is trigger_type parallel, it has no meaning, all the parent's children will get enabled, anyway - if parent action is trigger_type dynamic, same shit, no semantics @@ -597,7 +605,7 @@ trigger the parent action, the trigger condition would tell us whether to allow the trigger to go through.The trigger condition could check to see if all child cases are -completed, or it could check if there's enough to determine the +completed, or it could check if there's enough to determine the outcome, e.g. a 2/3 approval.
XXXXXXXXXXXXXXX @@ -607,7 +615,8 @@ gets to determine whether the parent action is now complete and should fire.We provide a default implementation, which simply checks if the -child cases are in the 'complete' state, and if so, fires.
+child cases are in the 'complete' state, and if so, +fires.NOTE: What do we do if any of the child cases are canceled? Consider the complete and move on with the parent workflow? Cancel the parent workflow?
@@ -621,14 +630,17 @@
Cases can be active, complete, suspended, or canceled.
They start out as active. For FSMs, when they hit a state with
-complete_p = t, the case is moved to 'complete'.
complete_p = t, the case is moved to
+'complete'.
Users can choose to cancel or suspend a case. When suspending, they can type in a date, on which the case will spring back to 'active' life.
When a parent worfklow completes an action with a sub-workflow, -the child cases that are 'completed' are marked 'closed', and the -child cases that are 'active' are marked 'canceled'.
-The difference between 'completed' and 'closed' is that -completed does not prevent the workflow from continuing (e.g. -bug-tracker 'closed' state doesn't mean that it cannot be -reopened), whereas a closed case cannot be reactivarted +the child cases that are 'completed' are marked +'closed', and the child cases that are 'active' are +marked 'canceled'.
+The difference between 'completed' and 'closed' +is that completed does not prevent the workflow from continuing +(e.g. bug-tracker 'closed' state doesn't mean that it +cannot be reopened), whereas a closed case cannot be reactivarted (terminology confusion alert!).
Callback: Action.OnFire -> (output): Executed when the -action fires. Output can be used to determine the new state of the -case (see below).
+Callback: Action.OnFire -> (output): +Executed when the action fires. Output can be used to determine the +new state of the case (see below).
The callback must enumerate all the values it can possible output (similar contruct to GetObjectType operation on other current workflow service contracts), and the callback itself must @@ -687,14 +701,14 @@ models.
-workflow.Action_OnFire: +workflow.Action_OnFire: OnFire -> string GetObjectType -> string GetOutputs -> [string]
GetOutputs returns a list of short_names and pretty_names -(possibly localizable, with #...# notation) of possible -outputs.
+(possibly localizable, with #...# notation) of +possible outputs.The above table could be merged with the current workflow_fsm_actions table, which only contains one possible new @@ -720,7 +734,7 @@ create table workflow_fsm_states( ... -- If this is non-null, it implies that the case has completed with - -- the given output, for use in determining the parent workflow's + -- the given output, for use in determining the parent workflow's -- new state outcome integer constraint @@ -734,8 +748,8 @@
An action does not become avilable until a given list of other actions have completed. The advanced version is that you can also -specify for each of these other tasks how many times they must've -been executed.
+specify for each of these other tasks how many times they +must've been executed.Also, an action can at most be executed a certain number of times.
-Action.CanEnableP -> (CanEnabledP): Gets called when -an action is about to be enabled, and can be used to prevent the -action from actually being enabled.
+Action.CanEnableP -> (CanEnabledP): Gets +called when an action is about to be enabled, and can be used to +prevent the action from actually being enabled.Is called after all database-driven enable preconditions have -been met, i.e. FSM enabled-in-state, and "gated on"-conditions.
+been met, i.e. FSM enabled-in-state, and "gated +on"-conditions.This will only get called once per case state change, so if the callback refuses to let the action become enabled, it will not be asked again until the next time an action is executed.
@@ -790,12 +805,13 @@ );If user_trigger_p is false, we do not show the action on any -user's task list.
+user's task list.The bug-tracker has resolution codes under the "Resolve" action. -It would be useful if these could be customized.
+The bug-tracker has resolution codes under the +"Resolve" action. It would be useful if these could be +customized.
In addition, I saw one other dynamic-workflow product (TrackStudio) on the web, and they have the concept of resolution codes included. That made me realize that this is generally @@ -856,13 +872,13 @@
When someone is assigned to an action, we want the notification email to say "You are now assigned to these tasks".
We'd need to postpone the notifications until we have fully +
We'd need to postpone the notifications until we have fully updated the workflow state to reflect the changed state, to determine who should get the normal notifications, and who should get personalized ones.
-Notifications doesn't support personalized notifications, but we -could use acs-mail/acs-mail-lite to send them out instead, and -exclude them from the normal notifications if they have instant +
Notifications doesn't support personalized notifications, +but we could use acs-mail/acs-mail-lite to send them out instead, +and exclude them from the normal notifications if they have instant notifications set up.
If the action is enabled:
If the action is not enabled.
Executed when an action which was previously not enabled becomes enabled.
Executed when an action which was previously enabled is no -longer enabled, because the workflow's state was changed by some -other action.
Executed when an enabled action is triggered.
We provide a default implementation, which simply checks if the -child cases are in the 'complete' state, and if so, fires.
+child cases are in the 'complete' state, and if so, +fires.NOTE: What do we do if any of the child cases are canceled? Consider the complete and move on with the parent workflow? Cancel the parent workflow?
@@ -940,7 +959,7 @@ never needed.When the action finally fires.
-If there's any OnFire callback defined, we execute this.
+If there's any OnFire callback defined, we execute this.
If the callback has output values defined, we use the mappings
in workflow_action_fsm_output_map to determine which
state to move to.
The timer will always be of the form "This action will -automatically execute x amount of time after it becomes enabled". -If it is later un-enabled (disabled) because another action (e.g. a -vote action in the second use casae above) was executed, then the -timer will be reset. If the action later becomes enabled, the timer -will start anew.
+automatically execute x amount of time after it becomes +enabled". If it is later un-enabled (disabled) because another +action (e.g. a vote action in the second use casae above) was +executed, then the timer will be reset. If the action later becomes +enabled, the timer will start anew.We currently do not have any information on which actions are -enabled, and when they're enabled. We will probably need a table, -perhaps one just for timed actions, in which a row is created when -a timed action is enabled, and the row is deleted again when the -state changes.
+enabled, and when they're enabled. We will probably need a +table, perhaps one just for timed actions, in which a row is +created when a timed action is enabled, and the row is deleted +again when the state changes.create table workflow_actions( @@ -1034,7 +1054,8 @@ workflow_actions.timeout_seconds .
NOTE: We need to keep running, so if another automatic action -becomes enabled after this action fires, they'll fire as well.
+becomes enabled after this action fires, they'll fire as +well.The sweeper will find rows in
workflow_case_enabled_actions with
@@ -1055,10 +1076,10 @@
timed action is inserted, we compare with the NSV, and update if
the new action fires before the old action. When the timed action
referred to in the NSV is either deleted because it gets
-un-enabled, or executed, we'll clear the NSV, causing the next hit
-to the sweeper to execute the query to find the (case_id,
+un-enabled, or executed, we'll clear the NSV, causing the next
+hit to the sweeper to execute the query to find the (case_id,
action_id, fire_timestamp) of the first action to fire. Finally, we
would need an NSV value to represent the fact that there are no
-rows in this table, so we don't keep executing the query in that
-case.
+rows in this table, so we don't keep executing the query in
+that case.