From my POV, Emergency and Routine change types are too much requiring approvals. So, I started looking at the model in order to modify their workflows by suppressing some steps, and I found these interesting lines for each Change type :
Could you please help me by explaining what are these 'ev_something' states, and how I could reduce all these steps by this workflow :
new -> assigned -> implemented -> closed ?
Thanks.
Of course, I'll let Normal change type for all changes requiring approvals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To configure the workflow for a given class of object iTop uses 3 definitions:
1) A list of "states"
2) A list of possible "events" (also called stimulus , the ev_xxxx definitions)
3) A list of transitions
When an object in a given state receive the specified stimulus, then this triggers a transition into another state with possibly the execution of an action (defined as a method of the object). Each stimulus corresponds to a possible "action" in the "Actions" menu.
The list of states is defined for all objects of the base class "Change", in a first approach it's simpler to let as is. But you can reconfigure the transitions for have a simpler life cycle for the class RoutineChange. For example, if you replace the whole list of DefineTransitions in the RoutineChange object by the following:
This topic is quite old, but I have an additional question to it.
I think new->assigned->implemented->closed is not enough because there must be at least an approval.
BUT: There is one big problem at the end of the process. The Title can be changed after the change is closed which is not really GxP compliant (even if the change is logged)
To make the title ReadOnly add the following lines to /modules/itop-change-mgmt-1.0.0/model.itop-change-mgmt.php
Hi,
From my POV, Emergency and Routine change types are too much requiring approvals. So, I started looking at the model in order to modify their workflows by suppressing some steps, and I found these interesting lines for each Change type :
MetaModel::Init_DefineTransition("new", "ev_assign", array("target_state"=>"assigned", "actions"=>array(), "user_restriction"=>null));
MetaModel::Init_DefineTransition("assigned", "ev_plan", array("target_state"=>"plannedscheduled", "actions"=>array(), "user_restriction"=>null));
MetaModel::Init_DefineTransition("plannedscheduled", "ev_implement", array("target_state"=>"implemented", "actions"=>array(), "user_restriction"=>null));
MetaModel::Init_DefineTransition("implemented", "ev_monitor", array("target_state"=>"monitored", "actions"=>array(), "user_restriction"=>null));
MetaModel::Init_DefineTransition("implemented", "ev_finish", array("target_state"=>"closed", "actions"=>array('SetClosureDate'), "user_restriction"=>null));
MetaModel::Init_DefineTransition("monitored", "ev_finish", array("target_state"=>"closed", "actions"=>array('SetClosureDate'), "user_restriction"=>null));
Could you please help me by explaining what are these 'ev_something' states, and how I could reduce all these steps by this workflow :
new -> assigned -> implemented -> closed ?
Thanks.
Of course, I'll let Normal change type for all changes requiring approvals.
Hi szauba,
To configure the workflow for a given class of object iTop uses 3 definitions:
1) A list of "states"
2) A list of possible "events" (also called stimulus , the ev_xxxx definitions)
3) A list of transitions
When an object in a given state receive the specified stimulus, then this triggers a transition into another state with possibly the execution of an action (defined as a method of the object). Each stimulus corresponds to a possible "action" in the "Actions" menu.
The list of states is defined for all objects of the base class "Change", in a first approach it's simpler to let as is. But you can reconfigure the transitions for have a simpler life cycle for the class RoutineChange. For example, if you replace the whole list of DefineTransitions in the RoutineChange object by the following:
You'll have your shorter life cycle…
Note that the constraints on the fields (for each state) defined in the base class via
still apply, so you may be prompted to enter/update many fields for each transition…
I did not test, but normally, you should be able to also redefine the constraint in the derived class using the same syntax…
Hi dflaven,
Thanks, it works, and as you mentioned, some fields are still left blank (as I bypassed the "PlannedScheduled" event)
This topic is quite old, but I have an additional question to it.
I think new->assigned->implemented->closed is not enough because there must be at least an approval.
BUT: There is one big problem at the end of the process. The Title can be changed after the change is closed which is not really GxP compliant (even if the change is logged)
To make the title ReadOnly add the following lines to /modules/itop-change-mgmt-1.0.0/model.itop-change-mgmt.php