The minimum required PHP version has been upped from 7.2.0 to 7.2.5.
It is now possible to define user roles for granular control on what parts of UI, which API methods, and which functionality (such as the ability to acknowledge problems) are available to end-users.
By default, Zabbix is configured with four user roles, which are automatically assigned to the corresponding user types during upgrade:
|Guest role||The same permissions as for Guest users (user type: User). Access to the Monitoring, Inventory, and Reports sections only, without rights to perform any actions. Access to API is disabled. After an upgrade, existing guest users will lose access to API and the ability to acknowledge problems - these settings can be changed later in the Guest role configuration form.|
|User role||The same permissions to access UI elements as for 'User' user type. Access to the Monitoring, Inventory, and Reports sections only. List of allowed actions has been modified - see the note below.|
|Admin role||The same permissions as for 'Admin' user type. Access to the Monitoring, Inventory, Reports, and Configuration sections.|
|Super admin role||Unlimited access permissions. This role cannot be deleted or modified because at least one Super Admin with a full set of rights must exist.|
Super Admins can delete or modify these roles, except of the Super Admin role, or create additional roles with custom sets of permissions.
List of API methods available to user types User and Admin has been modified. To view allowed methods, scroll to the Access to API section of the user role configuration form and press Select. Only the methods supported for this user type will be shown. It is possible to restrict some of the methods by specifying an Allow or Deny method list.
List of actions that users are allowed to perform is defined by the User role settings. By default, User role allows the following actions:
To restrict users from performing all or some of the actions, go to Administration → User roles, select the role User role and unmark required checkboxes in the section Access to actions. Press the Update button to save new settings.
The frontend time zone, previously set by the 'date.timezone' setting of php.ini, now can be set globally in the frontend and adjusted for individual users.
During the upgrade the time zone setting will default to "System" ensuring that everything works for users the same as before. With the System option, the web server time zone is used for the frontend (including the value of 'date.timezone' of php.ini, if set), while Zabbix server uses the time zone of the machine it is running on.
See also: Time zones
A separate setting for refreshing unsupported items has been removed from Administration → General → Other. Instead, the item update interval is now used for each unsupported item. This has been done to remove a potential performance bottleneck in the scenario when a lot of items turn unsupported and the global refresh interval has been set to a short value.
Host screens configured on the template level, or “template screens”, have been converted to template dashboards. The conversion of template screens will take place as soon as you launch the upgraded Zabbix server. As a result, the template screen elements will become the widgets of template dashboards.
Each template screen will be converted to a template dashboard preserving the name and the configuration and location of screen elements (now widgets).
However, it is not guaranteed that all screen elements will find their place on the converted dashboards, since screens can have a significantly larger width and height comparing to dashboards. In such cases Zabbix will discard the out-of-range screen elements, after trying to accommodate as many screen elements as possible by manipulating the size of newly created widgets.
Please make sure to back up your templates before the upgrade to 5.2.
Note that when importing an older template containing template screens into Zabbix 5.2 or later, the same screen-to-dashboard conversion principles will be applied.
Zabbix session is now stored in a user cookie.