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

Consider browsing to iTop 3.2 documentation

Remove a field from Ticket

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

learning:
Remove an existing field from a class
level:
Intermediate
domains:
XML, PHP, Portal, Lifecycle, Presentation
min version:
2.1.0

In order to remove a field, you must identify all the places where that field is used within the iTop XML datamodel. For this open the /data/datamodel-production.xml file of an installed iTop, before adding your extension. Save it somewhere as the reference.

For the urgency field of the UserRequest class, you should at least remove any appearance in this list:

  • itop_design / classes / class@UserRequest / fields / field@urgency
  • itop_design / classes / class@UserRequest / properties (naming, order, reconciliation, …)
  • itop_design / classes / class@UserRequest / lifecycle
  • itop_design / classes / class@UserRequest / presentation
  • itop_design / classes / class@UserRequest / methods
  • itop_design / module_designs / module_design@itop-portal / forms
  • itop_design / module_designs / module_design@itop-portal / classes / class@UserRequest
Some fields cannot be removed without breaking iTop, for example
  • org_id field on any class,
  • status field on any class with a lifecycle
  • caller_id field on Ticket
  • there are more fields, but that's a good start

Removing an existing field from the standard datamodel of iTop can break compatibilities with iTop extensions which would rely on the remove field.

Just hiding the field

You can decide just to hide the field to the user. In some case, it can be enough.

Hiding a mandatory field with no default value does not work.
  • On creation, submission will fail
  • If the field in mandatory within a transition, field will be prompt in transition form

Hiding in the Portal

A field can be hidden just for Portal User, as the forms used in a Portal are defined in XML and are independent from the Console one.

This is how to hide it on Ticket creation:

itop_design / module_designs / module_design@itop-portal / forms
<form id="ticket-create" _delta="must_exist">
  <twig _delta="redefine">
    <div class="row">
      <div class="col-sm-6">
        <div class="form_field" data-field-id="service_id" data-field-flags="mandatory"></div>
      </div>
      <div class="col-sm-6">
        <div class="form_field" data-field-id="servicesubcategory_id" data-field-flags="mandatory"></div>
      </div>
    </div>
    <div id="service_details_placeholder">
      <div class="form_field" data-field-id="service_details"></div>
    </div>
    <div class="row">
      <div class="col-sm-6">
        <div class="form_field" data-field-id="impact"></div>
      </div>
      <div class="col-sm-6">
      <!-- lines to be removed from default Portal
        <div class="form_field" data-field-id="urgency"></div>
      -->
      </div>
    </div>
    <div>
      <div class="form_field" data-field-id="title"></div>
      <div class="form_field" data-field-id="description"></div>
      <div class="form_field" data-field-id="contacts_list"></div>
    </div>
  </twig>
</form>
Changing this “twig” allow you also to change the way the Ticket is displayed on creation to the user

And this is how to hide it on Ticket Edition:

itop_design / module_designs / module_design@itop-portal / forms
<form id="ticket-edit" _delta="must_exist">
  <twig _delta="redefine">
    <div class="row">
      <div class="col-sm-7">
        <fieldset>
          <legend>{{'Ticket:baseinfo'|dict_s}}</legend>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="title" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="service_id" data-field-flags="read_only"/>
          </div>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="caller_id" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="servicesubcategory_id" data-field-flags="read_only"/>
          </div>
          <div class="col-sm-12">
            <div class="form_field" data-field-id="description" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="solution" data-field-flags="read_only"/>
          </div>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="user_satisfaction" data-field-flags="read_only"/>
          </div>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="user_comment" data-field-flags="read_only"/>
          </div>
        </fieldset>
      </div>
      <div class="col-sm-5">
        <fieldset>
          <legend>{{'Ticket:Type'|dict_s}} &amp; {{'Ticket:date'|dict_s}}</legend>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="status" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="impact" data-field-flags="read_only"/>
            <!-- <div class="form_field" data-field-id="urgency" data-field-flags="read_only"/> -->
            <div class="form_field" data-field-id="priority" data-field-flags="read_only"/>
          </div>
          <div class="col-sm-6">
            <div class="form_field" data-field-id="start_date" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="last_update" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="resolution_date" data-field-flags="read_only"/>
            <div class="form_field" data-field-id="agent_id" data-field-flags="read_only"/>
          </div>
        </fieldset>
      </div>
    </div>
    <div>
      <div class="form_field" data-field-id="contacts_list"/>
      <div class="form_field" data-field-id="public_log"/>
    </div>
  </twig>
</form>
The above forms are just examples from a particular installation of iTop 2.6.

Hiding in the Console

It can be hidden just in the Console, in the details presentation

  • This has no effect on the Portal
itop_design / classes / class@UserRequest
    <!-- Display the 2 new fields in the details of the UserRequest -->
    <presentation>
      <details _delta="must_exist">
        <items>
          <!-- Second column of the UserRequest display -->
          <item id="col:col2">
            <items>
              <!-- id of the fieldset should be found in datamodel-production.xml file -->
              <item id="fieldset:Ticket:Type">
                <items>
                  <!-- remove the urgency -->
                  <item id="urgency" _delta="delete"/>
                </items>
              </item>
            </items>
          </item>
        </items>
      </details>
    </presentation>

This does not fully remove the field, as it is still available through

  • CSV export,
  • in list though “Configure This List…” menu
  • CSV import
  • API REST/JSON

Removing the field

Field definition

Now we would like to completely removed the field from that class of object, which means also remove it from database. We need to remove the field from the class:

itop_design / classes / class@UserRequest / fields
        <field id="urgency" _delta="delete">
        </field>

Class properties

We need to check if the urgency field is used in:

  • the UserRequest friendlyname
  • the UserRequest reconciliation fields used for CSV import
  • the UserRequest obsolescence logic
  • the UserRequest uniqueness rules

As it's not the case here, we have nothing to do; otherwise we would have had to change them.

Lifecycle flags

We need to remove any reference to that field in the lifecycle of the class. In the case of urgency, flags are only set on state resolved, so just one XML node to set to “delete”:

itop_design / classes / class@UserRequest / lifecycle / states
   <state id="resolved">
      <flags>
        <attribute id="urgency" _delta="delete"/>
      </flags>
   </state>

Methods

We need to remove any reference to that field in the PHP methods defined on the UserRequest class

itop_design / classes / class@UserRequest / methods
   <method id="xxx">
      <code>
      <!-- check the PHP of each method as they could be relying on this code attribute -->
      </ code>
   </method>
To identify impacted PHP method, search for the code attribute

For example any reference to $this→Get('urgency') where $this is a UserRequest would crash iTop with a FatalError

The result of the urgency search within UserRequest methods, leads to ComputePriority method which need to be modified:

class:UserRequest
public function ComputePriority()
{
    // priority[impact][urgency]
    $aPriorities = array(
        // a department
        1 => array(
            1 => 1,
            2 => 1,
            3 => 2,
            4 => 4,
        ),
        // a group
        2 => array(
            1 => 1,
            2 => 2,
            3 => 3,
            4 => 4,
        ),
        // a person
        3 => array(
            1 => 2,
            2 => 3,
            3 => 3,
            4 => 4,
        ),
    );
    $iPriority = 1;
    if (isset($aPriorities[(int)$this->Get('impact')]) 
     && isset($aPriorities[(int)$this->Get('impact')][(int)$this->Get('urgency')]))
    {
         $iPriority = $aPriorities[(int)$this->Get('impact')][(int)$this->Get('urgency')];
    }
    return $iPriority;              
}

Presentation

As this urgency field is used also in the forms definitions, you must apply the 2 changes described above, as to say, deleting it in the Portal forms and in the presentation details. But this is not enough, maybe that field was specified in other part of the presentation, such as search, list and default_search

In our case, urgency was only defined in the search criterion, so we remove it:

itop_design / classes / class@UserRequest
    <presentation>
      <search>
        <items>
          <!-- remove the urgency -->
          <item id="urgency" _delta="delete"/>
        </items>
      </details>
    </presentation>

Dictionaries

In theory, we should also delete the corresponding dictionary entries, but not doing it as no effect on iTop behavior.

OQL queries

The removed field can be used in OQL queries stored

  • in the DataModel: for example on filter tag of External Keys,…
  • in Dashlets: defined in the datamodel or in user preferences
  • in QueryPhrases
  • in Audit rules
  • in bookmarked urls containing a Filter
  • in Notifications
  • in Configuration file parameters
  • and other places brought by extensions

Removing field on parent class

When removing a field on an abstract class, the search of usage within the XML must be done on the abstract class and all its sub-classes.
3_0_0/customization/remove-field.txt · Last modified: 2022/01/21 16:52 by 127.0.0.1
Back to top
Contact us