This document highlights issues which can occur while migrating your iTop to this version.

This document highlights issues which can occur while migrating your iTop to this version.

• For a focus on new features check What's New
• For an exhaustive list of changes check the Change Log
• For the list of Known Issues in 3.3 Beta version
• Combodo 3.3 compatible extensions versions

• New PHP min version: 8.2.0 (see backward incompatible changes list)
• New PHP max version: 8.4.x

As usual some extensions must be upgraded at the same time as your iTop, or after for ???4?? of them.

The DisplayBareProperties method id in DocumentFile changed from DisplayBareRelations to DisplayBareProperties to be more consistent with the defined function. If you have redefined this method, you will need to change the identifier.

If you have developed custom extensions with XML and custom code, check: Developer check-list

Check for each of your Combodo extensions the 3.3 compatible version that you need to install, before upgrading.

Using an undeclared SCSS variable as the value for another variable is deprecated. To ensure compliance with Sass specifications, please use static values (e.g., Hex codes) or variables that you defined beforehand.

As the User Portal New Look is now the only User Portal, all previous extensions customizing the portal theme are no more working.
A new extension must be written following the new standard: question_answers

The way to resolve those conflicts impose to modify your extensions and/or modify your model in the Designer.
There are different use cases:

• Node xxx/xxx/xxx already exists so cannot be created
  • Your customization have exactly anticipated the evolution brought by iTop 3.3 Datamodel ⇒ Remove your customization
  • Your customization is different also the node id is the same ⇒ replace the _delta=“define” by a _delta=“define_if_not_exists”
• Node yyy/yyy/yyy not found so cannot be modified/removed
  • if it wanted a removal ⇒ Remove your customization
  • if you wanted a modification ⇒ Check your modification to see if you can just replace the “redefine” by a “define” or if it requires to provide a wider XML branch to be effective.

This version adds fields to CMDB classes

• If you have redefined the presentation details of those classes by extension or with the Designer, those enhancements won't be visible in your iTop.
• If you have done any type of XML customization it can conflict with the 3.3.0 Datamodel changes. First conflict found is reported during iTop Setup, XML compilation phase. The error message identifies the module and node in conflict.
  • For the community, check the exhaustive list in the link above and adapt your XML extension(s)
  • For Combodo's customers, ask for the Migration Audit report, which will identify the conflicts with your customization if any.

• Service and Service Subcategory status are now mandatory.
  • Any such object with an undefined value will become implementation after upgrade
  • Those undefined were not visible in User Portal while implementation were visible (before upgrade)
  • After upgrade, unless you have modified those classes scopes in the User Portal implementation are no more visible in the User Portal except for Users with the Service Manager profile, so they can test new Service Subcategory (especially pertinent with Customized request forms).

• A new dashboard menu has been added (See iTop 3.3 Community)

If you have reorganized those menus, the new dashboard menu may appears without all its expected sub-menus

• New field parent_request_id on class Incident

• New prefix on log entries copied from parent Ticket + code refactoring:
  • new method on class Ticket UpdateChildTicketLog adding a prefix to the log entry copied from the parent Ticket and being more efficient
  • Modification of methods UpdateChildRequestLog and UpdateChildIncidentLog on classes UserRequest and Incident, to call Ticket::UpdateChildTicketLog
• The method can be reuse for any log
• Parent log and child log can be different, you can copy the public parent entry within the private child log if you want.
• The prefix is associated with the parent Ticket log, so it describes the source. A parent User Request public log entry, will always have the same prefix regardless where it is copied.

  'Class:UserRequest/Method:UpdateChildTicketWith:public_log' => '<i><u>Public log automatic copy from parent User Request %2$s:</u></i><br><br>',
        'Class:UserRequest/Method:UpdateChildTicketWith:private_log' => '<i>Private log automatic copy from parent User Request [[UserRequest:%1$s]]:</i><br><br>',
        'Class:Incident/Method:UpdateChildTicketWith:public_log' => '<i><u>Public log entry from parent Incident %2$s:</u></i><br><br>',
        'Class:Incident/Method:UpdateChildTicketWith:private_log' => '<i>Private log entry from parent Incident [[Incident:%1$s]]:</i><br><br>',

If you have configured a Trigger (on object creation) or a Trigger (on object deletion) on class Attachment, those triggers can no more be modified

You should replace it with the new classes of trigger brought by version 3.3.0:

• Trigger (on object's attachment creation)
• Trigger (on object's attachment deletion)

Before downgrading from 3.3.0 to a 3.2 iTop version

• Make sure these lines are at the end of the configuration file.

$MyModules = array(
        'addons' => array('user rights' => 'addons/userrights/userrightsprofile.class.inc.php'),
);

• Downgrade the package
• Run Setup