Reassign a Ticket on log update

Prerequisite: You must be familiar with the Syntax used in Tutorials and have already created an extension.

In this tutorial, we will see different solutions to force a User Request to be reassigned automatically to the agent, when the customer enter a new entry in the portal ticket caselog

In general, when the customer provided an information or asked a question in the user portal on an ongoing ticket, we want the ticket agent to be aware and react to the Ticket, the easiest being that the Ticket get reassigned to the agent. This is something rather easy to configure with the extension “Mail To Ticket Automation”, but it is not the case with the portal.

You will find below 2 different strategies which booth reach that objective:

1. Check if the log was updated in the portal and trigger a reassign transition in background - Recommended
2. Force the Portal User to update the Log through a transition which would reassign the Ticket

With an event EVENT_DB_BEFORE_WRITE (or EVENT_DB_AFTER_WRITE) and a callback method, if conditions matches, apply the appropriate stimulus to reassign the ticket

UserRequest

public function EvtReassignUserRequest(Combodo\iTop\Service\Events\EventData $oEventData)
{
        // Not in creation, nor in a transition
        if (!$oEventData->Get('is_new') && $oEventData->Get('stimulus_applied') === null) {
            $sStatus = $this->Get('status');
            if (ContextTag::Check('GUI:Portal') && in_array($sStatus, ['pending', 'resolved']))  {
 
                // Get the recent changes (depends on the event used to trigger this method!)
                switch ($oEventData->GetEvent()) {
                    case 'EVENT_DB_AFTER_WRITE':
                        $aChanges = $oEventData->Get('changes') ?? [];
                        break;
                    case 'EVENT_DB_BEFORE_WRITE':
                    default:
                        $aChanges = $this->ListChanges();
                }
 
                if (array_key_exists('public_log', $aChanges)) 
                {
                    $this->ApplyStimulus('ev_assign'); // This method does not do any control to check whether the current logged user is allowed or not to apply this stimulus
                }
            }
        }
}

It is possible to test a change in the public log with:

 if ($this->Get('public_log')->GetModifiedEntry('html') != '') 

This test can replace those lines:

                switch ($oEventData->GetEvent()) {
                    case 'EVENT_DB_AFTER_WRITE':
                        $aChanges = $oEventData->Get('changes') ?? [];
                        break;
                    case 'EVENT_DB_BEFORE_WRITE':
                    default:
                        $aChanges = $this->ListChanges();
                }
 
                if (array_key_exists('public_log', $aChanges))

In iTop 3.3 it generates the same result, even if the Portal User only past a simple inline image in the log, it is seen as modified and not empty.

Before or After, the 2 methods works with iTop 3.3.

itop_design | classes | class@UserRequest | event_listeners

        <event_listener id="EvtReassignUserRequest" _delta="define">
          <event>EVENT_DB_BEFORE_WRITE</event>
          <rank>10</rank>
          <callback>EvtReassignUserRequest</callback>
        </event_listener>

1. Deny the Caselog edition in the pending state

• With an event and a PHP callback method, make the caselog readonly if:
  • in the portal
  • in state pending
  • not in a transition

  /**
         * Event Listener for EVENT_DB_SET_ATTRIBUTES_FLAGS
         */
        public function EvtSetAttributesFlags(Combodo\iTop\Service\Events\EventData $oEventData)
        {
                // $oEventData->Get('target_state') returns null if we are not in a transition, otherwise it provides the target state of the transition
                if (ContextTag::Check('GUI:Portal') && ($this->Get('status') === 'pending') && ($oEventData->Get('target_state') == null)) {
                    $this->AddAttributeFlags('public_log', OPT_ATT_READONLY);
                }
        }

2. Change the stimulus used by the transition from pending to assigned, replacing ev_assign by ev_reopen which is a stimulus allowed to Portal User.

3. Force the edition of the caselog in the transition (must prompted)