Sometimes just the name of an object is not enough to identify it clearly, in this case, leave your mouse over its name, and after a delay, more information about that object is displayed in a popup, with the possibility to directly edit that object in full screen.

Multiple other classes do have a summary by default, more details.
You can add a summary on your own classes as well…

Useful when selecting objects in a drop-down list:

Person (email + org_name)

Trigger (class, Additional information)

Multiple other classes do have a complementary name, more details

We've simplified the way to create, add, modify, remove and delete related objects, proposing those actions without editing the current object.

If the user has the rights, they can add and remove sub-objects from the details view, without editing the current object it-self.

Example of a Ticket, on which one's can create, modify or delete associated Work Orders

• create

• modify

• delete

As long as the user is allowed to edit and delete the Work Order, regardless if he is allowed or not to modify the User Request, the above actions will be available for him.

It's now possible to add and remove related objects from the details view, without editing the current object it-self, which means that a user can do it even if he is not allowed to modify the current object, as long as he is explicitly allowed to modify the relationship or at least the remote class.

Example of a team, on which we want to:

• add a person,

• modify his role

• or remove from the team

The 3.1 iTop version brings a new way to handle many to many relationship which do not have attributes and are not expected to contain a lot of related objects.

For example a User can be linked to a few Profiles, with this new capability the Profiles can be selected in the properties tab of the object, so its easier not to forget to fill them.

Limitations

• There is still no visual indication that the relation is mandatory and not fed
• When an object is created/modified in a pop-up screen, relations tabs are not displayed, so you can't select any Allowed organizations.

• In 3.0.0, there is a comment field on the User to Profile relationship, which can be used to specify when and why this profile was given, it can even be the User Request reference justifying this access. But on the other hand there was no mean to comment a Profile removal.
• It could now be done from now on in the User log.

Other example, when creation / editing an Email Notification, you can choose the Trigger(s) directly the properties tab of the Notification

If the trigger you want does not exist yet, you can create it from here It will be added to the Related Triggers field after creation in pop-up.

If you are not at ease with this new mode, the reverse side of the relation is still using the tab display.

• This other view still allow to set the order relational field.

The buttons have moved to the right upper corner of the list

Attributes of many to many (n:n) relationship can be edit in User Portal.

Some attribute types are not supported, the constrains are the same as in console:

• multi-lines attributes (html, long text, caselog,…)
• File and Image
• TagSet and EnumSet
• LinkedSet

An ordered list of the link class attributes can be specified within the portal XML, to restrict the User Portal visible attributes.

Links related action/icon tooltip, pop-up window title and confirmation message, can be customized and specialized per class/attribute

Now in every list (dashlet list, object relation tab, run query result, …) you can click on

• the list count: Total: X objects
• or use the new action menu Display list with search criteria…

Both links will open the same query in full screen, with the corresponding search criterion set.

• You will then be able to change the filters, to reduce the results,
• run the menu “Configure this list” to modify the displayed fields, etc.

• In the case of a many to many relationship tab, the query includes the link and its fields.
• It offers bulk actions on those links and linked objects

When a list of objects returned more than one class of object, different new actions are proposed to users having bulk-modify right on those classes. For each class, if the user is allowed it proposes

• a bulk edit
• a bulk delete

You can end-up in this situation in the tab of a many to many relationship displayed in the details of an object. Such list contains two classes, the Link and the Remote class.

You can also end-up in this situation with a multi-classes OQL entered in

• a dashlet list
• a run query
• a shorcut

Example with a run query on 3 classes:

Notification: new layout

Trigger: new list

User: new layout and tooltip

Person: tab User added, of course, it is only visible to users being allowed to see the User class.

• A Person's organization can no more be changed if it has associated “Portal user” which would not be allowed on the new organization, as it would break the user access to iTop.

Problem: new details layout

3.0 layout	3.1 layout aligned to the User Request fields order and columns

Customer Contract and Provider Contract: new details layout with two columns and three fiedsets

Notification enriched tooltips proposing usable placeholders

Menu tooltip have been restored (they disappeared in 3.0.0)

Tooltip are more visible and available on tab title as well

A uniqueness rule has been added on all standard datamodel many to many links.
Check the migration notes section if you want to do the same on your custom links.

New XML tags allow to define the way a given enumeration attribute should display its values. See how to order values of enumeration attributes

It's now possible to order the transitions of classes with lifecycle, thanks to a configuration parameter and the default rang added on the standard datamodel on the Ticket classes.

Fields order in transitions forms now automatically follow the order set in the details tab of the class. There is no possibility to set a different order than in the details screen.

It's now possible to allow iTop Users without Administrator profiles, to query object history, just give them a profil with the new group History or use the Query History profile brought by the extension Admin tools delegation
Also be cautious that such users should not have “Allowed organizations” and should have read access on all classes with history tracking, because if they don't for security reason, it's not bulletproof as through the history they can see all those objects in little pieces, by their changes.

Feedback during CSV import have been improved, when reconciliation on enumeration value or external key are failing

• On enumeration, in case of no match, the allowed values are displayed
• On external key, in case of no match,
  • some of the existing values are displayed and a search button is proposed to check by yourself in another window
  • if there is no entries in iTop (or no entries visible to the current user), a message will tell you:
    • There are no 'Organization' objects
    • There are no 'Organization' objects found with your current profile

Now automatically returns on login screen

New dashboard to configure the audit

The improvements below are due to Combodo's historical partner Itomig. A big thanks to Lars Kaltefleiter!

Segmentation of the audit by Domain:

• Users can check audit related to their domain only, and not be bothered by errors they are not responsible to fix
• This improve the audit performance and even restore the audit capability on iTop which data have increased so much that audit is never ending anymore within reasonable time
• Limit the audit calculation to what is pertinent to the user requesting it

• From each audit category results, those who have enough rights, can jump with the wench icon on the Audit Category object, to adapt the rules if needed.
• With Hyperlinks configurator included for Combodo's customers, you can test the result of an audit domain, category or rule directly from those objects.

Colors threshold by category

• On each rule it is now possible to define the value of the thresholds which make the result good, poor or bad

New information added to the Query Phrase to track usage of each query, so you can clean-up no more used ones

• Total usage count
• Last user
• Last usage date

Email Notifications have been enhanced with new fields:

• A Language field, which allow placeholders to be translated in the language specified in this field, instead of the language of the user who triggered the notification.
• An HTML template file, which allow to send nice HTML email, without losing the possibility to contain placeholders. Note that you now have a preview.
• An Ignore the Notify flag field. If set to “No” it automatically discard Persons with Notification set to No from the TO, CC and BCC. No need to include this logic in your OQLs anymore.

This module provides two ways to use authentication token for API calls:

• Application token is a particular type of user in iTop.
  • It authenticates using a token and cannot connect to iTop UIs (Console, portal …)
  • It has its own profiles and allowed organizations
  • It can access all APIs (REST, Synchro, Export ..) with no possible restriction
• Personal token is linked to an iTop user
  • It authenticates using a token and cannot connect to iTop UIs (Console, portal …)
  • It inherits from its associated user, profiles and allowed organizations
  • It can be restricted to some of AOI (Just REST and Export for eg.)
  • Management of its own personal token can be delegate to users with particular profile

If your company security policy forces every users to authenticate through SSO SAML, then Personal Token is the solution to access iTop APIs, which do not support SSO SAML. Export used by Excel or PowerBI dynamic report, is one of those APIs.

Check the Authentication by Token module for more details

1. You have defined password policies, but this does not apply to existing passwords. You can massively update your iTop users to force them to change their password, and so guarantee that their new password will be compliant with your policy.

2. You can now force your iTop local users to change their password on a regular basis if you wish, by setting this module configuration parameter password_expiration_delay

Check the Password Expiration Management module for more details.

If you delegate User management to non-admin, they can't see Administrator Users.
To restore previous behavior, set to false the configuration parameter security.hide_administrators

Big system have a lot of data logged. Actual log system allow you to rotate log files to prevent having a too big content size but you still have all the files on server disk. We added a purge scheduled task to delete old files and free server disk space. Controlled with 2 new parameters:

• log_purge.enabled, boolean, default to false
• log_purge.max_keep_days, integer in day unit, default to 365

Previously to access debug messages in the portal, you had to activate the portal debug mode. To ease troubleshooting, debug messages can now be activated through the logs configuration like for any other parts of the application.

Concerned messages are:

• AggregatePageBrick not displaying
• Object not accessible for security reason (scopes misconfiguration, …)

A downloads counter was added to the ormDocument object (file attributes, attachments)

• Counter starts at 0 after migration, even for existing documents that have already been downloaded in the past.
• Display counter in attachments table (in object details).
• Does display counter on AttributeBlob.

A new Trigger (on object's document download) is available, it will be activated when someone downloads a file attribute (eg. File on the Document File class) in the backoffice or the end-user portal.

This trigger gives you access to new placeholders in the actions (of course the standard ones are still available):

• $file->mime_type$ Mime type of the file (eg. “image/png”)
• $file->file_name$ Name of the file, as uploaded.
• $file->downloads_count$ Number of time the file has been downloaded. Note that it is the count BEFORE the current download, so you can hook some checks to prevent it if a threshold is exceeded.
• $file->data$ Binary content of the file
• $file->data_as_base64$ Base64 encoded content of the file, can be useful for integrations with other apps

A new Trigger (on object's attachment download) is available, it will be activated when someone downloads an attachment in the backoffice or the end-user portal.

This trigger gives you access to new placeholders in the actions (of course the standard ones are still available):

• $attachment->xxx$ Same possibilities as for $this->xxx$ but with the attachment itself ($this being the object it is attached to)
• $attachment->mime_type$ Mime type of the file (eg. “image/png”)
• $attachment->file_name$ Name of the file, as uploaded.
• $attachment->downloads_count$ Number of time the file has been downloaded. Note that it is the count BEFORE the current download, so you can hook some checks to prevent it if a threshold is exceeded.
• $attachment->data$ Binary content of the file
• $attachment->data_as_base64$ Base64 encoded content of the file, can be useful for integrations with other apps

In previous versions to launch the setup it was mandatory to modify the config file permission, so you needed to access your server filesystem.

Now a button is available in the “Application Upgrade” screen (integrated from PR #244).

This button will be available depending of a conjunction of the isdevenv property (see \utils::IsDevelopmentEnvironment) and the setup.launch_button.enabled config parameter. See the below table for a list (❌ = no value defined, 👻 = hidden, 💻 = displayed) :

When writing a module, the model.*.php file can be specified ('datamodel' key in the module.*.php file) even if the file isn't generated by iTop compilation.

Also, if a datamodel.*.xml file is present in a module, the compiler will automatically picked it to generate the corresponding model.*.php.
Starting with iTop 3.1.0 it won't be necessary anymore to declare the model.*.php file (in the 'datamodel' key in the module.*.php file) as it will automatically be added to the datamodel autoloader by the compiler.

The exec.php script is used to execute a script inside a module. For example an Ajax endpoint.

With this script you can now specify the script to execute and a subdirectory. For example : exec.php?exec_module=mymodule&exec_page=ajax/endpoint.php&exec_env=production

See PR #221.

Sometimes the need fora custom zlist with a restricted / specific list of attributes is necessary. With iTop 3.1+ you can now define your own custom zlists and use them like the standard ones using \MetaModel::GetZListItems(). See here for more details.

Since 2.7.0 a new way to generate the ref field has been introduced. This could cause ref and id field values to be different.

When building an object detail URL from an external system (for example Bugtraq), this could cause problems as parameters are class and id.

An existing workaround is to send the friendlyname value in the id parameter… but this is only possible when the friendlyname only contains no other fields than ref.

To address uses cases where friendlyname contains multiple fields (title, org, …), you can now use new URL for both console and user portal. For example for an object having id=99 and ref=100 :

/pages/UI.php?operation=details&class=UserRequest&id=99
/pages/UI.php?operation=details&class=UserRequest&attcode=ref&attvalue=R-000100


/pages/exec.php/object/view/UserRequest/99?exec_module=itop-portal-base&exec_page=index.php&portal_id=itop-portal
/pages/exec.php/object/view/UserRequest/ref/R-000100?exec_module=itop-portal-base&exec_page=index.php&portal_id=itop-portal

If none or multiple instances are found, then you'll get:

• admin console : exception is thrown
• user portal : 404 error page

See PR #273