This extensions aims at improving the end-users productivity. It automatically creates a set of prefilled objects out of existing data.

Amongst the possible usages, you can:

• Preset work orders on a user request, depending on the selected service, to be executed when the request is being assigned to an agent.
• Preset a list of characteristics on a contract, depending on the selected service, to be recorded right when a contract is being created.
• Preset the SLAs depending on …
• Preset server interfaces

This can be combined with Object Copier… for instance: Create a “Move to production” request from a CI. The request gets automatically (or not) assigned, then the work orders are prefilled.

Note that in most cases you will have to alter the existing data model to define your template class.

The templates will be copied under the following circumstances:

• either when an object is being created
• or when an object is reaching a given state (lifecycle required)

The objects being in the scope of the trigger can be filtered out by the mean of an OQL: SELECT UserRequest WHERE team_id_friendlyname='Doers'.

Once the triggering conditions have been met, the module will perform the following:

1. Look for the templates. This is done by the mean of an OQL. E.g. SELECT WorkOrderTemplate WHERE service_id = :trigger->service_id
2. For each template,
   1. Instantiate an object called the copy
   2. Perform a series of action on the copy. This is formalized as a list of actions. For instance, “clone(description)+set(ticket_id,$trigger->id$)” will copy the attribute description from the template, then set the parent ticket to be the ticket that triggered the copy
   3. Optionaly find the children of the current template, and for each child perform the same operations; (i.e. a + b + c, recursively)
3. Optionaly perform a series of actions (set a value, apply a stimulus) back on the triggering object.

A report is displayed (though this is optional) on the triggering object:

These are the limitations of Object Copier.

The following types of attributes are currently not handled and therefore cannot be preset (and no error message is given):

• 1-N links (e.g. Server Interfaces)
• Blobs
• Stop watches

The workaround is to use the verb 'call_method' (new in 1.0.4) and implement your need as a method of the destination object.

Use the Standard installation process for this extension.

A rule is made of…

An action is specified as a string having formatted as “verb(arg1[,arg2[…]])”. It implies a source object and a destination object. Source and destination objects both depend on the context in which the series of actions is defined:

• copy_actions: source is the current template object, destination is the corresponding copy
• copy_from_trigger ( new in 1.0.4 ): source is the triggering object, destination is a copy
• retrofit_from_copy: source is a top level copy, destination is the triggering object
• retrofit: source and destination are the triggering object

The following verbs are available:

Available placeholders:

• $this->attcode$ where this represents the source object
• $trigger->attcode$, where trigger represents the triggering object (only for copy actions)
• $current_contact_id$
• $current_contact_friendlyname$
• $current_date$
• $current_time$

Limitations

• Before 1.1.2 with iTop 2.4.0 or above, if you have defined a custom date format for your iTop, the a date attribute is not decoded correctly when using $this->attcode$ or $trigger->attcode$​, leading to an error | Error | itop-stencils: rule #3 - Action: set(start_date,$trigger->start_date$) - Wrong format for date attribute start_date, expecting "Y-m-d H:i:s" and got "13-12-2018 00:00:00".
• From 1.1.2 (and iTop from 2.4.0) for Date (or DateTime) attributes only, the following syntax as to be used:
  
  • $this->​raw(attcode)$ or $trigger->​raw(attcode)$​

'itop-stencils' => array(
   'rules' => array(
      array(
         'name' => 'Work orders',
         'trigger_class' => 'UserRequest',
         'trigger_scope' => 'SELECT UserRequest',
         'trigger_state' => 'assigned', // triggered when reaching this state
         'report_label' => 'A task list has been created for the ticket', // Label or dictionary entry
         'report_label/FR FR' => 'Une liste de tâche a été créée pour ce ticket',
         'templates' => 'SELECT WorkerOrderTemplate WHERE service_id = :trigger->service_id', // A query to define how to look for the templates
         'copy_class' => 'WorkOrder', // Class of the copied templates
         'copy_actions' => array( // Series of actions to preset the object in the creation form
            'clone(name)',
            'clone(description)',
            'set(ticket_id,$trigger->id$)',
            'set(team_id,$trigger->team_id$)',
            'set(agent_id,$trigger->agent_id$)',
         ),
         'copy_hierarchy' => array(
            'template_parent_attcode' => 'parent_id',
            'copy_parent_attcode' => 'workorder_parent_id'
         ),
         'retrofit' => array( // Series of actions to retrofit some information from the created object to the source object
            'set(private_log,A task list has been created for the ticket)',
         ),
      ),
   ),
),

All errors are logged to the file log/error.log

The behavior from the end-user perspective is:

• If no template have been found, the rule is ignored
• If an error is found (wrong OQL, the target object cannot be written, …) nothing is shown in the GUI.