You are browsing the documentation for iTop 2.7 which is not the current version.

Consider browsing to iTop 3.1 documentation

Planned User Request (advanced)

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

learning:
Add a state and count time spent in it
level:
Advanced
domains:
XML, Stopwatch, Automation, Lifecycle
min version:
2.3.0

In this tutorial, we will explore further User Request where TTO start on a planned date tutorial, proposing solutions for the identified limitations:

  • Why using AfterInsert and not iApplicationExtension
  • How to take into account a modification of the “planned date”, after the creation, during new or scheduled state?
  • How to prevent the other transitions to be proposed?

FIXME FIXME FIXME FIXME FIXME FIXME FIXME FIXME FIXME

Work in progress…

Question & Answers

Question: Why automatically switch to a state “scheduled” when a planned_date is proposed?
Answer: This mechanism is the one used by Auto dispatch ticket to a team and Approval process automation

But you could decide to propose this transition as a user choice and on that transition, make the planned_date field mandatory, but in that case, if combined with Approval process automation, user won't be able to schedule a UserRequest which is under approval, unless you schedule after approval. There is an imcompatibility if you use Auto dispatch ticket to a team as the Request might be auto-dispaltched before you schedule it. Then add also an ev_schedule transition from dispatched to scheduled, so that the user can still scheduled a dispatched Ticket. Hopefully when pushed back to new after the delay, it will be dispatched again.

When using iApplicationObjectExtension it's officially not possible to define the order in which classes implementing this interface will be called, but for the case of Approval extented which we wanted to execute before AutoDispatch, we have done it by a optional module dependency, which implies a module load ordering, which until now is the same as the calling ordering. FIXME Nous ne voulons pas en faire la publicité, car ça pourrait bien changer !!!!

Question: When you create a UserRequest with a date and we do Assign, it crashs with Fatal Error, how to avoid it?
Answer: Extensions Auto dispatch ticket to a team and Approval process automation hide in the console (FIXME and in portal?), all other actions which could be failing such as “Assign”, “Dispatch”, “Wait for approval”,…

You can avoid this by overloading DisplayBareProperties()

class:UserRequest
function DisplayBareProperties(WebPage $oPage, $bEditMode=false, $sPrefix='', $aExtraParams=array())
{
    $aFieldsMap = parent::DisplayBareProperties($oPage, $bEditMode, $sPrefix, $aExtraParams);
    if ($bEditMode && $oObject->GetState()='new')
    {
        $oPage->add_ready_script(
<<<EOF
    $('button.action[name="next_action"]').hide();
EOF
        );
    }
    return $aFieldsMap;
}

or by implementing iApplicationUIExtension (OnDisplayProperties()) as the listed extensions are doing.

main.my-extension.php
   public function OnDisplayProperties($oObject, WebPage $oPage, $bEditMode = false)
   {
      // Hiding transition buttons
 
      if ($bEditMode && $oObject instance of UserRequest && $oObject->GetState()='new')
      {
         $oPage->add_ready_script(
<<<EOF
    $('button.action[name="next_action"]').hide();
EOF
         );
      }
   }

Risk of overwriting

When you define one of the DBObject overwritable methods, be aware that it may have been done already within the standard iTop datamodel. If it is the case, at setup/toolkit compilation, as you add the method with a _delta=“define” it will fails if it exists already. In that case, you can do a “redefine”, but then mirror the existing code or you will break the current behavior of iTop.

For example in the Standard Datamodel, the class UserRequest defines already those methods

class:UserRequest
public function ComputeValues()
{
    $this->Set('priority', $this->ComputePriority());
    return parent::ComputeValues();
}
public function DoCheckToWrite()
{
    parent::DoCheckToWrite();
    if (!$this->IsNew() && ($this->Get('parent_request_id') == $this->GetKey()))
    { $this->m_aCheckIssues[] = Dict::Format('Class:UserRequest/Error:CannotAssignParentRequestIdToSelf'); }
}
protected function OnInsert()
{
    $this->ComputeImpactedItems();
    $this->SetIfNull('last_update', time());
    $this->SetIfNull('start_date', time());
}
protected function OnUpdate()
{
    parent::OnUpdate();
    $aChanges = $this->ListChanges();
    if (array_key_exists('functionalcis_list', $aChanges))
       {  $this->UpdateImpactedItems();  }
    $this->Set('last_update', time()); 
    $this->UpdateChildRequestLog();
}
2_7_0/customization/add-activation-delay2.txt · Last modified: 2020/04/15 15:23 (external edit)
Back to top
Contact us