• Beta version 2.7.0 release date: December 18th 2019
• 2.7.0 release date: April 2020
• 2.7.1 release date: July 2020
• 2.7.2 release date: Nov 2020
• 2.7.3 release date: Dec 2020
• 2.7.4 release date: March 2021
• Download link
• Read before upgrading: Migration notes
• List of changes across iTop history: Cumulative Change Log

We have reworked the attachment display, with new ordering capabilities and additional information displayed such as

• who has uploaded the file,
• when this upload occurred,
• what is the size and type of the file.

• The legacy portal code has been removed from iTop package. iTop portals since version 2.3, should be written based on the enhanced Portal design.

• A new icon, allows to copy the url to the displayed object, to provide it to a colleague or the support agent.
• When a user portal clicks outside of a pop-up window in which he has entered some data, he is asked with a confirmation message, instead of loosing his entries.
• When the user cancels or submits a Ticket form, it now displays a refreshed version of the ongoing tickets.
• Contacts linked to a Ticket and displayed within the Ticket form are limited to the contacts that the user is allowed to see.
• External keys attributes displayed in forms are now clickable as in the Console, to open the related object in his own pop-up above the current form.

• Navigation rules allows a Portal developer to specify where to go, when a Portal user cancels or submits a form, in modal or non-modal mode.
• The Browse Brick now supports to connect two levels not only with a 1:n relationship but also a n:n. So for example, you can define Customer Contracts as the first level, then Service as the second level, and Service Subcategory as the third one.
• When n:n related objects (AttributeLinkedSetIndirect) are displayed in a form, a new parameter allows to limit the displayed objects to those allowed to the user, or to display all of them (as it was done before 2.7).
• Number of displayed objects in a page for a Browse and a Managed Brick, can be specified.

More details here

A new theme has been added which just add a top banner to the console, so you can differentiate your iTop test instance from your production environment Test theme is called 'test-red'. iTop comes with a light-grey theme by default.

Configuration

    // This line should be added on the iTop test instance only
    'backoffice_default_theme' => 'test-red',

Those new themes also allow you to change Console colors with just XML knowledge.

If you are a Web developper, you can more easily customize iTop Look & Feel thanks to new attributes added to html tags within iTop pages, details here

You can insert within a description or a caselog a piece of php, xml, sql,… code and display it nicely, using syntaxe highlighting (using http://qbnz.com/highlighter/)

The results will look this way:

Pop-up window displaying a tree of objects, is now only displaying the first level of the tree and offers two actions to Collapse All and Expend All.

Working from iTop 2.7.1 and above

• Security: restrict access over /env-xxx

When creating a new user password or changing an existing user password, a password policy is now applied.
The password must have at least 8 characters with lowercase, uppercase, number and special character.

You can remove this default policy, by adding this in $MyModuleSettings array of the Configuration file:

Configuration

      'authent-local' => array (
                'password_validation.pattern' => '',
        ),

More details: User password policies

There is an API to check passwords used in Local Authentication

• Password complexity can be controlled with a Regex out of the box. An extension can add/replace it by other controls.
• Password renewal date was added to the UserLocal object and is automatically computed when the user or an administrator change the user password
• Password expiration can be coded in an extension, using available fields Password renewal and Password expiration flag to force a change of password.

If you are a developer, you can write an extension, to:

• Authenticate your iTop users with Single Sign On (SSO) - SAML, OAuth or OpenID (Facebook, Twitter, GitHub, Google,…)
• Automate user provisioning on his first connection to iTop
• Customize login/logoff forms to align them to your corporate standards
• Apply Security Policies on Local users

Authentication can rely on different protocols:

• Some have been supported for years:
  • AuthLocal
  • AuthLDAP
  • External authentication, mainly used for CAS
    • CAS configuration is now in the modules part, but the old global cas_ parameters are still working.

Some are new 2.7 possibilities which must be coded using the iTop authentication API:

• SAML (45 parameters)
• OAuth/openID (Facebook, Twitter, GitHub, Google… +27 existing applications)
• Multiserver LDAP

External applications can provide information about the user:

• Facebook (like Google and probably others) provide first-name, last-name, email, which can be used to provision the user within iTop, in order to create a user and a contact on the fly.
• Cautious GitHub only provides the login for eg.

You can change the login and logoff screens to:

• Add a background image
• Add web links to other web sites
• Add other authentication mecanisms
• Request additional information to complete user provisioning for eg.

Example of a possible screen customization

You've dreamed about it, we made it: You can now perform in a single OQL query, what was only possible through Audit rules.

• Teams without members

SELECT Team WHERE id NOT IN (SELECT Team AS t JOIN lnkPersonToTeam AS l ON l.team_id=t.id)

• Change Tickets without FunctionalCI linked to it
• Users not allowed on their own organization
• and many more…

Check here for more examples

Create notification that takes into account which application has activated the trigger, if it was the CRON, a REST application, someone in the Console, in a Portal, and so on… This information is called contexts.

• If you have different Portals, you can notify different people depending on the Portal used.
• You can notify people only if a DataSynchro or a REST application has modified a particular field, but not if that modification was done in the Console or on a Portal.

Check details here

With iTop 2.7.0 and above, iTop administrators can upgrade or downgrade their iTop, directly from iTop web interface (console), without having access to the iTop server.
More details here

With iTop 2.7.0, the log management for error.log and setup.log include a rotation system that allows to archive such file by day, week or by month.

For the corresponding period the system check if the error.log and setup.log file has to rotate. If yes a copy of the file is done with the convention error.<xxxx>.log

• Day: error.2020-02-28.log
• Week: error.2020-week09.log
• Month: error.2020-month02.log

This is as well handle by a cron task : LogFileRotationProcess

The frequency is configure using the parameter log_filename_builder_impl. This parameter is set by default to monthly rotation. But it is not visible by default in the Configuration file.

The administrator can use variables within the Configuration file. When editing that file using iTop UI, those variables are now preserved when saving the file. This allows to define a Configuration file, applicable regardless of the environment in which you will deploy your iTop. This follows recommendations for deployment on modern cloud platforms: Best practice.

Configuration

    'db_host' => $_ENV['DB_HOST'],

We have added a parser to prevent an administrator to put active code in the Configuration file (function calls, system commands,…) within the online editor. If you want to do this, which is not recommended, you must edit the file on your system and disable the online edition.

In order to be compatible with MySQL8, we had to change the way the Ticket reference is generated.

Overview:
Before version 2.7, iTop was

1. positioning a lock on the root object table,
2. getting the next id to use,
3. processing with the object insertion in database,
4. freeing the lock

Step 3 can take a lot of time especially with complex impact analyses and/or with synchronous notifications. Because of the locking mechanism, no other iTop users were allowed to create a Ticket during that time, so to fix this we have changed the logic starting from 2.7.0, now iTop is:

1. Positioning a lock on a counter table
2. getting next id to use
3. freeing the lock
4. processing with the object insertion in database

The consequence are that if step 4 does not complete as expected (creation fails for whatever reason), then the Ticket reference number has increased by one, while the key in the Ticket table did not (table key = id in iTop). This explain the de-correlation of ids.

More details:

MakeTicketRef method is called within DBInsertNoReload. You should change the code from:

class Ticket

public function DBInsertNoReload()
{
      $oMutex = new iTopMutex('ticket_insert');
      $oMutex->Lock();
      $iNextId = MetaModel::GetNextKey(get_class($this));
      $sRef = $this->MakeTicketRef($iNextId);
      $this->SetIfNull('ref', $sRef);
      $iKey = parent::DBInsertNoReload();
      $oMutex->Unlock();
      return $iKey;
}

to:

public function DBInsertNoReload()
{
      $iCounter = ItopCounter::IncClass(get_class($this));
      $sRef = $this->MakeTicketRef($iCounter);
      $this->SetIfNull('ref', $sRef);
      return parent::DBInsertNoReload();
}

MetaModel::GetNextKey is deprecated it is now an alias to ItopCounter::IncClass.

Keeping the first code should still work for now, also it may generate serious performance issue.

Restoring ids correlation:

If you want to keep the correlation between id and Ref you can use the following method.

1. Suppress de method DBInsertNoReload() on the class Ticket
2. Add the following AfterInsert method on the class Ticket

protected function AfterInsert()
{
        $iKey = $this->GetKey();
        $sRef = $this->MakeTicketRef($iKey);
        $this->SetIfNull('ref', $sRef);
        $this->DBUpdate();
}

You need to automate some behavior on object modification which depends on the previous value. It's now possible to get access to that previous value using \DBObject::ListPreviousValuesForUpdatedAttributes() within those two functions:

• \iApplicationObjectExtension::OnDBUpdate
• \DBObject::AfterUpdate

When writing logs you can now pass new parameters :

• channel: enable log filtering based on an extension, a feature, a class name, a PHP namespace,…
  • If not given, the default channel is the class log name (IssueLog, SetupLog, …)
• context: if given, the context will be written alongside the log.

The default log level is all of them except Debug. This can be tuned using the configuration parameter log_level_min: it leverages the possibility to filter the logs below a given level on a per channel basis.

The following API have been deprecated in iTop 2.7 and will be removed in a future version.

• Config::GetDB* methods : deprecated in 2.5.0
• 'db_character_set' and 'db_collation' config parameters : deprecated in 2.5.0
• DBBackup::CreateZip method : deprecated in 2.4.0
• Remove \DBObject::RegisterCallback

• Change visibility of \DBObject::GetReferencingObjects from public to protected
• \DBObject::DBInsertTracked
• \DBObject::DBInsertTrackedNoReload
• \DBObject::DBUpdateTracked
• \DBObject::DBDeleteTracked
• \CMDBObject::DBInsertTracked
• \CMDBObject::DBInsertTrackedNoReload
• \CMDBObject::DBUpdateTracked
• \CMDBObject::DBDeleteTracked
• \MetaModel::EnumLinksClasses
• \MetaModel::EnumLinkingClasses
• \MetaModel::GetNextKey : see ticket_ref_generation
• MySQL views (\MetaModel::DBCheckViews)
• since 2.7.6 : \Combodo\iTop\Portal\Controller\AbstractController::ForwardFromRoute
• since 2.7.6 : \Combodo\iTop\Portal\Controller\AbstractController::GetControllerNameFromRoute

- Tags <submit> and <cancel> will no longer be supported in action rules, use navigation rules instead.