A new ZBX_URI_VALID_SCHEMES constant has been added which defines the URI schemes that are allowed by default (http, https, ftp, file, mailto, tel, ssh).
All URLs in the frontend should be checked if they contain an allowed scheme.
Note that starting with Zabbix 3.4.5, URI scheme validation can be turned off/on.
The option list for acknowledgement message recipients has been reworked. See What's new for more details.
Permissions to dashboards have been changed for the Zabbix Admin type of users. See What's new for more details.
LLD rule processing has been modified so multiple values for the same LLD rule are not processed simultaneously.
Previously all values for LLD rules were processed in a context of data gathering process (for example, a trapper). This could cause deadlocks when separate values of a single low-level discovery rule were being processed in more than one data gathering process.
LLD rule locking is implemented in the configuration cache. A new piece of LLD data will be discarded if the previous one hasn't been fully processed yet. To avoid such possible delays with LLD value processing it is recommended, for example, to increase the polling interval for LLD rules or not send LLD JSONs with zabbix_sender too frequently. Discarded LLD data is not considered an error. zabbix_sender can report a value as “processed” even if the value was discarded. All cases of discarded LLD data are listed in the Zabbix server log file in the following format:
<TIMESTAMP> cannot process discovery rule "host:key": another value is being processed
Previously Zabbix would enforce PLAIN as the authentication mechanism when using username/password. Now libcurl may decide on its own which mechanism among those supported by the SMTP server to choose. With the parameters Zabbix passes to libcurl it effectively means choosing between PLAIN and LOGIN on most occasions. This is enough to enable Zabbix operation with Office 365 and should be enough for Gmail provided that “less secure apps” are allowed.
In previous 3.4.x versions, problems for a deleted item/trigger could not get deleted by housekeeper if they were not in a resolved status. From now on, if housekeeping of events is enabled then deleting an item/trigger will also delete events and problems generated by that item/trigger. If housekeeping of events is disabled then only problems of a deleted item/trigger will get deleted.
An optional database patch to clean up problems for deleted items and triggers has also been added.