Main thing that you cannot miss: the layout, the colors, the icons, the menus,… all this has totally changed, to make it more readable, leave more space to the important information, highlight the things that matter to you, so you can be more efficient.
Main changes on the possible actions:
The Quick search is now on the left.
This feature can now be configured through new configuration parameters global_search.xxx, which allow to:
Brand new feature:
It allows you to quickly create any object without knowing where is the menu to do it, if even there is one.
Just type the beginning of the class you want, and you are proposed with the matching classes.
This feature can be configured through configuration parameters quick_create. .xxx, which allow to:
The version 3.0 has improved how an object is displayed:
The header part has been totally reworked:
New modes to display the contents of an object, defining how you can switch from one tab to another:
Classic: this mode behave as before:
Scrollable: this mode is new:
A new panel has been added, to speed-up a pretty common situation in which the agent just need to provide a reply within a log entry and maybe apply a transition.
More details in the User's Manual
In this part of the screen, that we have named the “activity panel”, you retrieve the logs and the history, all merged in a single timeline, which makes it more efficient to understand the full history.
The history timestamps are relative when recent and absolute above a specified delay.
History display can be configured with new Activity Panel parameters.
In the console an agent may want to quickly notify someone within a caselog to get their attention.
mention
, the person will receive an email notification.
Do you remember how painful it was to loose the column titles when scrolling within a list? This is over, now they remains visible while you scroll down.
At the same time the search criterion used to filter the list remains on the screen.
Note also the colored circles associated with status value.
User Manual for managing list.
Dashboard look has been improved, with new icons and graphical chart
The menus have been enriched with icons and can be shrunk to display just the icons, thus gaining space for the valuable information
A quick way to go back to iTop homepage!
branding
Number of objects in predefined queries
99+
indicates that they are more than 99. Alt+M
on Chrome to search in menus without the mouse
Display of relationships in read and edit mode are now identical in terms of displayed fields.
It's much faster now to replace a team member by another one, just by editing their name. This new logic is available on all many to many relationships.
The version 3.0 brings new user preferences to control the behavior of iTop, so you can choose the modes that suits best your habits.
You can control when an iTop object is displayed:
If you like to navigate quickly just with the keyboard, we have added shortcut for frequent actions.
Check here for how to manage your User Preferences.
EN US
, FR FR
and DE DE
)Template for OQL fields
and having the exact same Expression
(OQL).Template for OQL fields
, are proposed when editing any iTop field of type OQL
, as a new action to retrieve existing queries and easily copy the OQL from the selected OQL Query.iTop now supports natively the possibility to connect to multiple LDAP servers
The following modifications was made in order to prevent admins or users to commit suicide.
If any of the above actions must be done, then another user must do it.
If you have implemented user delegation, then a new configuration parameter allow to improve those users experience by preventing them from editing Administrators and getting after that, an error message, by simply hiding to them those Administrator users. See security.hide_administrators configuration parameters.
Allow on any existing triggers to
More details about this feature included in 3.0.0 Products and as extension on iTop 2.7.x
view_ClassName
are now systematically removed during Setup.In CLI mode the JSON data structure can now be put in a separate file and in the command line, you just provide the path of the file, like this json-data@<path>.
With iTop 3.0 it's now possible with an iTop extension or through the ITSM Designer to
Sometimes a friendlyname is not enough to differentiate 2 objects, especially when you want to select it within a drop-down list. In order to cope with this, iTop 3.0 brings a new concept, to differentiate homonyms.
Check that new page for details on methods available, usable as action on transitions.
A new log file is added in 3.0.0 : log/deprecated-calls.log
.
This will contains logs of calls to deprecated files or PHP methods, and will help developers to migrate their code. Actually parts of the iTop API marked with @deprecated
are usually removed in the next iTop major version : ie a method marked as @deprecated
in iTop 3.0.0 will certainly be removed in iTop 3.1.0.
By default those logs are disabled, but you can enabled them using the log_level_min
config parameter for the appropriate log channels. Also, the logger will have a different behavior if used on a GitHub clone.
See the corresponding documentation for reference.
This feature is an optimization of the setup to spare significant time with themes (about 30 seconds per theme).
for more details see theme precompilation.
Some iTop behaviors intended for extensions and core developers are triggered by the \utils::IsDevelopmentEnvironment method : Twig cache reset, setup symlinks, DeprecatedCallsLog, …
This method was returning true only for Github clones.
Now the new developer_mode.enabled
config parameter allows to control the method returned value : if the parameter has a boolean value then it will be used as the method return value, otherwise the existing behavior will be kept.
Default config parameter value is null
so that nothing changes unless an explicit value is set.
This option is available only if all of the following conditions are met :
developer_mode.enabled
configuration parameter is set to true)symlink
PHP function is availableIf the setup is launched in such environment,a new option is displayed in the setup, in the “Miscellaneous Parameters” wizard step:
When the compilation is done with the option checked, a /data/.compilation-symlinks
file is created.
Also if this file is present the setup checkbox will be checked. It will be the same in the 3.0.0 toolkit for the corresponding option.
Note that this file will be used to generate symlinks when compilation is launched from any client that aren't providing the useSymLinks
parameter to the compiler (\MFCompiler::Compile
). Eg. ITSM Designer connector, Hub connector, custom script calling RuntimeEnvironment.
This is a gain for extension developers : if you are developing using the toolkit with the symlinks option, and if you need to launch the setup, you will get directly symlinks. Before it was mandatory to compile again using the toolkit to get back symlinks.
Since commit c5d265f6 in iTop 3.0.0 the compiler now will always remove the previous file when it needs to write a model.*.php
file. This implies the model.*.php
files won't ever be generated as a symlink.
If the compilation was done with the symlink option, below is a short summary of this behavior change consequences:
Has model.*.php | Has datamodel.*.xml | Consequence |
---|---|---|
✔ | ❌ | ➖ Modification done in the original model file will need a new compilation to be pushed in iTop |
✔ | ✔ | ➖ Same as above ➕ If your module is versionned (Git, Svn, …), you won't get the compiled code in model.*.php |
❌ | ✔ | ➕ Same as above |