Configuration Parameters

Located in the the conf/production directory, the file itop-config.php contains all the configuration parameters of iTop. This file is created during the setup, and updated upon upgrade.

If you have done some modifications to the settings, please backup this file prior to executing an upgrade, because the file will be generated again by the upgrade program. For example, comments will be lost.

The configuration file contains the following sections:

• MySettings: contains iTop settings. Some settings are not visible in the file generated by the installation program. These are settings for troubleshooting or disabling some features (workaround for complex integrations).
• MyModuleSettings: contains module settings.
• MyModules: lists the PHP files to include. It is a way to disable -temporarily- an installed feature. Depending on your need for language support, you might comment out some lines. This can speedup significantly the execution of every single iTop page. Please note that those changes will be lost when upgrading iTop.

Since the iTop configuration is stored - and processed - as a PHP document, PHP code injection is possible via the configuration editor. If you think that letting iTop administrators interactively edit the configuration file is too risky (for example if iTop is installed on a server shared with other applications), you can completely disable the interactive configuration editor. To disable the interactive editor, set the following configuration parameter (in the 'module_settings' section of the configuration file):

conf/production/config-itop.php

'itop-config' => array( 
    'config_editor' => 'disabled', 
)

Within values of any config parameters, if you type a \ after saving it is automatically doubled and becomes \\ when reopening the file. This behavior is normal and has no adverse impact. Don't change it again, it is useless.

By default the “global search” feature performs a search on each and every class and attribute defined in iTop. When the database grows, this can become very slow. Using accelerators, an administrator can specify, for a given class, how to search - in less fields - in order to speed up the search. It is also possible to completely exclude a given class from the search.

Example:

conf/production/config-itop.php

'full_text_accelerators' => array (
  'UserRequest' => array (
    'skip' => false,
    'needle' => '%$needle$%',
    'query' => "SELECT UserRequest WHERE (status != 'closed') 
                AND (ref LIKE :needle OR title LIKE :needle OR description LIKE :needle)",
    'attributes' => array('title', 'description'),
    'enable_enlarge' => true,
  ),
  'Person' => array (
    'query' => 'SELECT Person WHERE (name LIKE :needle) 
                OR (first_name LIKE :needle) OR (email LIKE :needle)',
    'attributes' => array ('name', 'first_name', 'email'),
  ),
),

For a given non-abstract class, the parameters are:

• skip (optional) if present, and equal to true, then the whole class will be skipped from the global search (unless the end-user specifically requires to search in this class by typing NameOfTheClass:string_to_search in the global search).
• query determines both the scope of objects to search for, and the columns that will be looked up. The entered search string is represented by the parameter :needle
• attributes (optional) must match the attributes used in the query so that the system will optimize its execution time.
• needle is optional and defaults to “%$needle$%”. It specifies how to make the :needle parameter out of the user search string.
• enable_enlarge (optional) if present and equal to false, the button Enlarge search will be hidden. When Enlarge Search is clicked, iTop performs the default complete search (all attributes) for the specified class of objects

This configuration parameter specifies the formatting of date and time fields in the application. The configuration can be specified by default and overloaded per language. If an entry (either date, time or date_time) is omitted in a given language, the corresponding default entry will be used. If no value is specified at all, the system will supply its own fallback value.

• The date entry specifies the format for dates. The fallback value is Y-m-d (MySQL format),
• The time entry specified the format for times. The fallback value is H:i:s (MySQL format),
• The date_time entry specifies how to assemble date and time in order to produce a complete date/time representation.

The syntax is the following:

'date_and_time_format' => array(
    'default|language_code' => array(
        'date' => 'date_format',
        'time' => 'time_format',
        'date_time' => 'combination_of_date_time_values',
    ),
)

Values for the date format:

Values for the time format:

Values for the date_time format:

The example below produces the following result:

• For users which language is configured to French (FR FR):
  • the dates are written: <day on two digits>/<month on 2 digits>/<year on 4 digits>, for example: 21/04/2016
  • the times are written: <hours, 24 hour clock, on 2 digits>:<minutes on two digits>, for example: 14:35
  • the date and times are written: <date> <time>, for example: 21/04/2016 14:35
• For users which language is configured to German (DE DE):
  • the dates are written: <day on two digits>.<month on 2 digits>.<year on 4 digits>, for example: '21.04.2016'
  • the times are written: <hours, 24 hour clock, on 2 digits>:<minutes on two digits>, for example: 14:35
  • the date and times are written: <date> <time>, for example: 21.04.2016 14:35
• By default (for all other languages):
  • the dates are written: <year on 4 digits>-<month on 2 digits>-<day on two digits>, for example: 2016-04-21
  • the times are written: <hours, 24 hour clock, on 2 digits>:<minutes on two digits>:<seconds on two digits>, for example: 14:35:09
  • the date and times are written: <date> <time>, for example: 2016-04-12 14:35:09

'date_and_time_format' => array(
    'default' => array(
        'date' => 'Y-m-d',
        'time' => 'H:i:s',
        'date_time' => '$date $time',
    ),
    'FR FR' => array(
        'date' => 'd/m/Y',
        'time' => 'H:i',
        'date_time' => '$date $time',
    ),
    'DE DE' => array(
        'date' => 'd.m.Y',
        'time' => 'H:i',
        'date_time' => '$date $time',
    ),
)

The code to use to specify a transition is the transition code such as ev_close.

It is possible to set a different list of shortcut actions per class, by overwriting the DBObject::GetShortcutActions method

itop-design / classes

    <class id="Incident">
      <methods>
        <method id="GetShortcutActions" _delta="define">
          <static>true</static>
          <access>public</access>
          <type>Overload-DBObject</type>
          <code ><![CDATA[
        public static function GetShortcutActions()
        {
                return array('UI:Menu:Modify');
        }
        ]]></code >
        </method>
      </methods>
    </class>

New in 2.4.2:

• the standard search is executed as soon as a search criteria is defined.
• when using the magnifier icon on an ExternalKey attribute, the search is executed.
• when searching objects to be added on a LinkedSetIndirect attribute (n:n relationship), the search is executed.

On classes with high volume of data and if filtering is not defined, it might be better to force the user to decide when he has entered enough criterion to make the search effective.

This can be done in the Configuration file by defining the classes for which you want this behavior to be applied.

Configuration

    'high_cardinality_classes' => array (
      0 => 'Contact',
      1 => 'Person',
      2 => 'UserRequest',
    ),

You can also instead, force this behavior for all classes at once, using this:

Configuration

      'search_manual_submit' => true,
        ),

In this example, for Person, users must explicitly press the search icon to get the resulting list aligned with the set criterion. There is a warning message to remind users about this different behavior.

Unless you customize your iTop Datamodel, this are the default criterion defined.
Default criterion is optional. They are inherited from parent classes if not defined.

We have chosen those criterion because they are the most used for single object search, which is what simple users would do. Advanced users will know how to add/remove criteria.

Predefined requests such as menus and shortcuts, will not use those defaults as soon as they come with their own criterion.

For each class of AsynchronousTask processed by the iTop background process (i.e. cron.php), it is possible to configure whether or not to retry the processing in case of failure. This can be especially convenient for the eMails sending. Since the name of the asynchronous task in charge of sending the eMails is AsyncSendEmail, the configuration look like:

'async_task_retries' => array(
    'AsyncSendEmail' => array(
        'max_retries' => 3,
        'retry_delay' => 30,
        'exponential_delay' => true,
    ),
),

With such a configuration, if the eMail fails to send, the backround process will reschedule this email to be sent up to 3 times. The first time 30 seconds later, the second time 60 seconds (after the 2nd attempt) later and finally the third time 120 seconds later.

If exponential_delay is not specified or set to false, the time between two attempts will be the same: retry_delay.

Some part of iTop written as independent Module, brings their own set of parameters, which are located in the Configuration file under the section:

conf/production/config-itop.php

/**
 *
 * Modules specific settings
 *
 */
$MyModuleSettings = array(
    // One array per module...
);

The default setting is not present but would look this way in Configuration file.

Configuration

$MyModuleSettings = array(
   'authent-local' => array (
      'password_validation.pattern' => '^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^\da-zA-Z]).{8,}$',
   ),
);

More details: User password policies

When displaying the Impact Analyses tab of a Ticket, or when displaying from a Functional CI the actions Impacts… and Depends on…, the Changes and Incidents displayed are calculated based on OQL queries configured in XML. As such they can be overwritten by a extension.

datamodels/2.x/itop-request-mgmt/datamodel.itop-request-mgmt.xml

  <parameters id="itop-config-mgmt"><relation_context><FunctionalCI><impacts>
    <down><items type="array"><item id="open_incidents" _delta="define">
      <oql><![CDATA[SELECT FCI, R FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id 
      JOIN UserRequest AS R ON L.ticket_id = R.id WHERE (R.status NOT IN ('closed', 'resolved')) 
      AND (R.request_type='incident') AND (L.impact_code != 'not_impacted')]]></oql>
      <dict>Tickets:Related:OpenIncidents</dict>
      <icon>itop-request-mgmt/images/incident-red.png</icon>
      <default>yes</default>
    </item></items></down>
    <up><items type="array"><item id="open_incidents" _delta="define">
      <oql><![CDATA[SELECT FCI, R FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id 
      JOIN UserRequest AS R ON L.ticket_id = R.id WHERE (R.status NOT IN ('closed', 'resolved')) 
      AND (R.request_type='incident') AND (L.impact_code != 'not_impacted')]]></oql>
      <dict>Tickets:Related:OpenIncidents</dict>
      <icon>itop-request-mgmt/images/incident-red.png</icon>
      <default>yes</default>
    </item></items></up>
    </impacts></FunctionalCI></relation_context>
  </parameters>

But they can also be overwritten through parameters in the Configuration file, if you have customized lifecycles of your tickets.

The default module_parameters if nothing is defined in the Configuration file, are available under /core/main.php Here is an example of a full itil iTop:

core/main.php

  'itop-tickets' =>        array (
    'relation_context' =>  array (
      'UserRequest' =>     array (
        'impacts' =>       array (
          'down' =>        array (
            'items' =>     array (
              0 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\', \'rejected\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id)',
                'dict' => 'Tickets:Related:OpenChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-ongoing.png',
              ),
              1 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id) AND (C.end_date < NOW() AND C.end_date > DATE_SUB(NOW(), INTERVAL 3 DAY ))',
                'dict' => 'Tickets:Related:RecentChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-done.png',
              ),
              2 =>         array (
                'oql' => 'SELECT FCI, I FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Incident AS I ON L.ticket_id = I.id WHERE (I.status NOT IN (\'closed\', \'resolved\')) AND (L.impact_code != \'not_impacted\') AND (I.id != :this->id)',
                'dict' => 'Tickets:Related:OpenIncidents',
                'icon' => 'itop-incident-mgmt-itil/images/incident-red.png',
                'default' => 'yes',
              ),
            ),
          ),
        ),
      ),
      'Incident' =>        array (
        'impacts' =>       array (
          'down' =>        array (
            'items' =>     array (
              0 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\', \'rejected\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id)',
                'dict' => 'Tickets:Related:OpenChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-ongoing.png',
              ),
              1 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id) AND (C.end_date < NOW() AND C.end_date > DATE_SUB(NOW(), INTERVAL 3 DAY ))',
                'dict' => 'Tickets:Related:RecentChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-done.png',
              ),
              2 =>         array (
                'oql' => 'SELECT FCI, I FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Incident AS I ON L.ticket_id = I.id WHERE (I.status NOT IN (\'closed\', \'resolved\')) AND (L.impact_code != \'not_impacted\') AND (I.id != :this->id)',
                'dict' => 'Tickets:Related:OpenIncidents',
                'icon' => 'itop-incident-mgmt-itil/images/incident-red.png',
                'default' => 'yes',
              ),
            ),
          ),
        ),
      ),
      'Change' =>          array (
        'impacts' =>       array (
          'down' =>        array (
            'items' =>     array (
              0 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\', \'rejected\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id)',
                'dict' => 'Tickets:Related:OpenChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-ongoing.png',
              ),
              1 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\')) AND (L.impact_code != \'not_impacted\') AND (C.id != :this->id) AND (C.end_date < NOW() AND C.end_date > DATE_SUB(NOW(), INTERVAL 3 DAY ))',
                'dict' => 'Tickets:Related:RecentChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-done.png',
              ),
              2 =>         array (
                'oql' => 'SELECT FCI, I FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Incident AS I ON L.ticket_id = I.id WHERE (I.status NOT IN (\'closed\', \'resolved\')) AND (L.impact_code != \'not_impacted\') AND (I.id != :this->id)',
                'dict' => 'Tickets:Related:OpenIncidents',
                'icon' => 'itop-incident-mgmt-itil/images/incident-red.png',
                'default' => 'yes',
              ),
            ),
          ),
        ),
      ),
    ),
  ),

  'itop-config-mgmt' =>    array (
    'relation_context' =>  array (
      'FunctionalCI' =>    array (
        'impacts' =>       array (
          'down' =>        array (
            'items' =>     array (
              0 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\', \'rejected\')) AND (L.impact_code != \'not_impacted\')',
                'dict' => 'Tickets:Related:OpenChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-ongoing.png',
              ),
              1 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status IN (\'closed\')) AND (L.impact_code != \'not_impacted\') AND (C.end_date < NOW() AND C.end_date > DATE_SUB(NOW(), INTERVAL 3 DAY ))',
                'dict' => 'Tickets:Related:RecentChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-done.png',
              ),
              2 =>         array (
                'oql' => 'SELECT FCI, I FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Incident AS I ON L.ticket_id = I.id WHERE (I.status NOT IN (\'closed\', \'resolved\')) AND (L.impact_code != \'not_impacted\')',
                'dict' => 'Tickets:Related:OpenIncidents',
                'icon' => 'itop-incident-mgmt-itil/images/incident-red.png',
                'default' => 'yes',
              ),
            ),
          ),
          'up' =>          array (
            'items' =>     array (
              0 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status NOT IN (\'closed\', \'rejected\')) AND (L.impact_code != \'not_impacted\')',
                'dict' => 'Tickets:Related:OpenChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-ongoing.png',
              ),
              1 =>         array (
                'oql' => 'SELECT FCI, C FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Change AS C ON L.ticket_id = C.id WHERE (C.outage = \'yes\') AND (C.status IN (\'closed\')) AND (L.impact_code != \'not_impacted\') AND (C.end_date < NOW() AND C.end_date > DATE_SUB(NOW(), INTERVAL 3 DAY ))',
                'dict' => 'Tickets:Related:RecentChanges',
                'icon' => 'itop-change-mgmt-itil/images/change-done.png',
              ),
              2 =>         array (
                'oql' => 'SELECT FCI, I FROM FunctionalCI AS FCI JOIN lnkFunctionalCIToTicket AS L ON L.functionalci_id = FCI.id JOIN Incident AS I ON L.ticket_id = I.id WHERE (I.status NOT IN (\'closed\', \'resolved\')) AND (L.impact_code != \'not_impacted\')',
                'dict' => 'Tickets:Related:OpenIncidents',
                'icon' => 'itop-incident-mgmt-itil/images/incident-red.png',
                'default' => 'yes',
              ),
            ),
          ),
        ),
      ),
    ),
  ),

Define the classes of objects which can have attachment, how those attachments are displayed and previewed
New in 2.4: readonly_states defines under which environment, which object classes in what status, will prevent adding and deletion of attachments.

'itop-attachments' => array(
    'allowed_classes' => array(
        0 => 'Ticket',
        1 => 'Contact',
    ),
    'readonly_states' => array(
        'all' => array(
            'UserRequest' => array('closed',),
            'Change' => array('rejected','closed',)
        ),
        'portals' => array(
            'UserRequest' => array('resolved',),
        ),
    ),
    'position' => 'relations',
    'preview_max_width' => 290,
    'icon_preview_max_size' => 500000,
),

iTop OQL won't be able to retrieve the biggest attachment loaded in your iTop, but you can run the next SQL command in your database to retrieve attachments bigger than 1 Mo.

 SELECT `item_class`, `item_id`,`item_org_id`,`contents_data`,`contents_mimetype`, `contents_filename` 
   FROM attachment 
   WHERE LENGTH(contents_data) > 1000000;