iTop 2.7 Community LTS
-
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
-
2.7.5-1 release date: July 2021
-
2.7.6 release date: January 2022
-
2.7.7 release date: July 2022 - add support of OAuth2 (for eg. connection to Office365 and gmail)
-
2.7.8 release date: December 2022
-
2.7.9 release date: August 2023
-
2.7.10 release date: January 2024
-
Read before upgrading: Migration notes
-
List of changes across iTop history: Cumulative Change Log
What's new in iTop Community
This is the first Long Term Support version for iTop. It will last between 3 and 4 years, until a new LTS is published
Ergonomics
New display for Attachment
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.
Attachment
tab.Portal
-
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.
New behaviors
-
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.
New customization possibilities
-
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
Console Look & Feel
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
Highlighting code
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:
Hierarchy navigation
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
-
Security: restrict access over /env-xxx
Password Policy
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
andPassword expiration
flag to force a change of password.
API authentication
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
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
User provisioning
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.
Login screen customization
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
Features
OQL: NOT IN SELECT
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
Notify based on context
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
Application upgrade
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
Log Rotation
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.
Variables in Configuration
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.
MySQL8 compatibility
In order to be compatible with MySQL8, we had to change the way the Ticket reference is generated.
Ticket Ref generation
Ticket
id
is no more used to build the reference and so can
differ from the number included in the Ticket
ref
Overview:
Before version 2.7, iTop was
-
positioning a lock on the root object table,
-
getting the next id to use as ticket reference,
-
processing with the object insertion in database,
-
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:
-
Positioning a lock on a counter table
-
getting the next counter value to use as ticket reference
-
freeing the lock
-
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 <2.7.0
-
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:
- class Ticket from 2.7.0
-
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.
-
Suppress de method DBInsertNoReload() on the class Ticket
-
Add the following AfterInsert method on the class Ticket
protected function AfterInsert() { // Don't do it if Ref and ID are already desynchonized $iKey = $this->GetKey(); $sRef = $this->MakeTicketRef($iKey); // Be cautious, a ticket may already exist with that ref // Before doing this you may search for such Ticket // and if there is one, change the ref, for eg append a 'b' at the end $this->Set('ref', $sRef); $this->DBUpdate(); }
AfterUpdate
method at migration time. Before any ID
ref de-synchronization occurs, to avoid having two Tickets
with the same ref, which can be a serious issue$this->hyperlink()$
For developers
Get object changes
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:
-
\DBObject::AfterUpdate
Logs filtering
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.
Deprecations
The following API have been deprecated in iTop 2.7 and will be removed in a future version.
Removal
-
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
Deprecate
-
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)
Customer portal
- Tags <submit> and <cancel> will no longer be supported in action rules, use navigation rules instead.