Sidebar

Using iTop

Creating your iTop

iTop Customization

"How to" examples
DataModel

User Interface

Automation & Ticket management

Portal Customization

:: Version 3.2.0 ::

Reassign a Ticket on log update

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

learning:
Reassign a Ticket on log update in the portal
level:
Intermediate
domains:
XML, PHP
min version:
3.1.0

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. This is something rather easy to configure with the extension “Mail To Ticket Automation”, but it is not the case with the portal.

There are multiple ways to achieve this. I propose you 2 methods:

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

Update through a transition

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.

As you only want to allow this particular transition and not the other “Assigned” transitions and because the access rights are just based on the stimulus name, you must change the stimulus used for that transition

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

Force transition in background

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

UserRequest
public function EvtAfterWriteUserRequest(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']))  {
                // The list of changes done during this operation
                $aChanges = $oEventData->Get('changes') ?? [];
                if (array_key_exists('public_log', $aChanges))
                {
                    $sStimulus = ($sStatus === 'resolved') ? 'ev_reopen' : 'ev_assign';
                    $this->ApplyStimulus($sStimulus);
                }
            }
        } 
}
3_2_0/customization/reassign-on-log-update.txt · Last modified: 2025/08/12 14:41 by 127.0.0.1
Back to top
Contact us