· In the spirit of St. Nicholas Day, we are excited to unveil our present to you: Zammad 6.2! 🌟🎁 This minor release comes bearing several enhancements aimed at elevating the efficiency and security of our helpdesk platform.
Zammad's group management just got an upgrade! Now, it works like a family tree, connecting parent groups to child groups and even grandparent groups. Think of it as a way to mimic how larger companies organize themselves. Just like teams within organizations, Zammad's groups are designed for collaboration on assigned topics. They offer a framework for organizing tasks, help in managing access to information and focusing on particular areas of responsibility.
Picture this: as a company grows, things get more complex. More departments, more teams – you get the idea. To keep up, we've made Zammad more flexible. Now, you can create group trees that mirror your organizational structure. It's like a visual map that shows what is connected to what, making things a lot easier to manage.
However, there is no inheritance of membership or permissions. That means you can treat each group as an individual group - even if they have a child/parent relation. ➡️ Read more on Group Settings in the admin documentation.
A powerful LDAP integration that allows you to have a single source of truth is one of our many great features of Zammad. Historically, when setting up a new LDAP source in our configuration wizard there was no need for authentication. However, in response to the evolving landscape of modern LDAP interfaces, Zammad has undergone adjustments. Specifically, we've implemented changes to facilitate the addition of new sources like Okta LDAP that mandate authentication.
Now, if your LDAP system restricts anonymous bind, Zammad 6.2 is equipped to identify this constraint. Consequently, instead of a pre-filled select field, Zammad presents users with an editable "Base DN" text field.
➡️ Find out more in our admin documentation.
Custom certificates and custom Certificate Authority (CA) certificates can be useful if you want to establish a secure connection between Zammad and other systems that use custom certificates. For example, if you have an internal LDAP server that is not accessible from the internet, and you want a SSL-encrypted connection, using a custom certificate.
With Zammad 6.2 we have created a way to add these certificates in the admin panel. Simply navigate to Settings > Security > SSL Certificates, and there, you'll discover the 'Add SSL Certificate' button. In the dialog, choose to either upload a certificate file or directly insert the certificate content.
🚨 Important: for existing configured external connections such as email or LDAP, SSL verification will not be turned on automatically. Admins need to review all configured connections and turn on SSL verification where applicable (e.g. in case of publicly available services).
➡️ Find out more in our admin documentation.
Please note: You should have an existing custom certificate file and/or a custom CA certificate file, which you want to add to Zammad. As filetype .crt is supported and the certificate format has to be PEM (Base64 ASCII).
Apropos LDAP: we previously covered the process through which Zammad 6.2 establishes a new LDAP source with authentication requirements. However, what if the LDAP setup prohibits the use of an LDAPS (LDAP via SSL) connection?
Anticipating this scenario during the development of Zammad 6.2, we implemented an alternative solution. Instead of SSL, Zammad 6.2 provides the option of STARTTLS as an encryption method. Now you can choose between different encryption types, namely SSL and STARTTLS or none of them, based on your specific LDAP configuration needs.
➡️ Read more on LDAP sources in the admin documentation.
Quick login to all your devices and systems - this has long been possible in Zammad via SAML. But we didn't want to stop at convenience. By leveraging this powerful synergy, we looked to extend the capabilities to allow the configuration of signed or encrypted requests. Consider it done - with our latest release, you can specify whether you prefer your requests to be signed, encrypted, both, or nothing at all.
➡️ Find out more in our admin documentation.
When working with Zammad tickets, it can be very handy to pull information from other sources. Instead of manually importing/copying the selected data into Zammad (and dealing with the headache of updates in two places), we've made it easy for users to select a related entity from external sources.
Let's say you want to fetch data from an external product database and thus add your products to tickets. Well, in Zammad 6.2, we've got you covered with the new attribute type called the 'External Data Source field.' Once the connection to the data source is established, you can search and select products from a list. Additionally, you have the option to create a link to the source, which, in this scenario, would be the product website.
➡️ Read everything about External Data Sources Configuration in our admin documentation.
Please note: Currently, only GET is supported as request method and the data structure must be in JSON format.
Communication systems represent an enormous reservoir of data, continuously accumulating volumes of messages and attachments containing information about customers, employees, and IT systems. This poses the challenge of efficiently managing this data in accordance with legal retention policies, often involving manual deletion processes.
With Zammad 6.2, that manual approach is a thing of the past. Administrators can now establish rules once, aligning with their company's data privacy and retention policy. Consequently, user data or other object data, such as tickets, undergoes automatic deletion after a specified time and specific conditions, all while maintaining a deletion history.
Wondering how we managed to do this? We expanded our scheduler's selection field by adding additional objects, including tickets, users, and organizations. ➡️ Read all about it in the admin documentation.
Attention: Please use Schedulers with Action: Delete immediately and Action: Add a data privacy deletion task with care! If executed, the objects are deleted and no rollback is possible.
Speaking of data, the increasing volumes of attachments for tickets and the knowledge base demand adequate storage space. By default, Zammad writes to the Database. While we recommend switching to filesystem storage for instances with higher loads, Zammad also provides a third option: Simple Storage (S3), a cloud-based storage service that enables you to store and retrieve data over the internet.
To use the Simple Storage (S3), set the "Storage Mechanism" in Zammad to Simple Storage (S3) under System in Settings. However, before doing so, it's essential to configure the connection to the service with Zammad.
➡️ In our admin documentation you will find a comprehensive step-by-step instruction.
Default SSL Verification in UserAgent
The default SSL behaviour of the UserAgent class in Zammad was changed. Previously, it would not perform SSL verification unless explicitly requested. Now, it will perform SSL verification unless explicitly rejected.
This may cause issues on systems with custom addons using the UserAgent to access other systems via https, if these systems have self-signed certificates. In such cases, these certificates or the CA certificates used for their generation should be uploaded via the new SSL Certificates management screen of Zammad. Alternatively, custom code can be adjusted to pass verify_ssl: false to UserAgent calls to restore the old behaviour.
Oversized Email Handling
The handling of emails larger than the size limit changed. Previously, Zammad would send a reply and save the emails locally in var/spool/oversized_email (if the setting postmaster_send_reject_if_mail_too_large is true). No ticket is created in this case.
The new behaviour is that Zammad sends the reply like before, but no longer creates files for these emails locally - they are discarded.
Reserved Delimiter in Group Name
The double colon (::) is now a reserved delimiter in the group name, in order to facilitate nested structure for complex hierarchies. Previously, it was possible to freely use this set of characters as part of the group name, but now it is forbidden.
On existing systems, the group names that contain the now reserved delimiter will be renamed, with sets of double colons being replaced by a dash (-) during the migration process.
Additionally, existing custom group object attributes named name_last and parent_id will be renamed too, by adding an underscore in front (_name_last and _parent_id). This is due to these attributes now being part of the group model, requiring dedicated table columns under the reserved names.
Disallowed URL Values in User's Name Attributes
Text values that resemble valid URI addresses are now disallowed for user's first and last name attributes. Previously, it was possible to save any text in these attributes. The administrators should take a note of this change since it can have an impact on existing user data.
No migration will be run for existing users on update to Zammad 6.2. In case there are user records that contain URLs in their name attributes, they will be sanitized during subsequent updates. No manual action from administrator will be required, as the URI scheme or protocol will be automatically stripped from offending values.
Documentation
The admin documentation now includes multi-language support (which was already available for the user documentation). We have published the translated German and Serbian versions, which you can find here (DE) and here (SR). If you want to contribute to the documentation and/or translation, please have a look at our contribution section in the system documentation.
Docker / Kubernetes Images for ARM64
With Zammad 6.2, images for deployment on Docker / Kubernetes are available both for traditional AMD64 but now also for modern ARM64 platforms.
Linux Distribution Support Changes
In the future, Zammad will provide binary packages for the last two stable/long-term support versions of supported Linux distributions until they reach their end-of-life or can no longer meet the technical requirements for Zammad. Use of the latest supported stable/long-term support version is generally recommended.
Zammad 6.2 will not provide packages for CentOS 7, Debian 10, Ubuntu 18.04, and SLES 12. Users of these distributions are advised to upgrade to newer versions such as CentOS 8, Debian 12, Ubuntu 22.04, and SLES 15.
Twitter/X Integration Removal
Due to the unclear situation regarding Twitter/X APIs, we consider removing the Twitter/X integration with the release of Zammad 7.0. Please have a look here for more information and updates on this topic.
Note about MySQL deprecation
Zammad is designed to provide our users with a secure and stable platform that is convincing in its performance. For this, the choice of supported database systems is crucial. After long discussions and based on our long experience, we have decided that Zammad will only support PostgreSQL as a database in the future. However, this change will not take effect until Zammad 7.0.
Until then, we do not recommend new installations with MySQL/MariaDB. Existing systems will continue to be supported, but must be migrated to PostgreSQL until the release of Zammad 7. For this purpose, we have provided a detailed Migration Guide that can be used to migrate existing systems to PostgreSQL free of charge.
This decision was not easy for us. However, we see it as necessary, because we want to continue to provide you with a long-term and reliable platform and keep the effort for everyone within limits.
Slack Integration Deprecation
Starting with Zammad version 7.0, we will no longer support this particular Slack integration. It is recommended that you switch to pre-built webhooks instead, a new feature of ours. Existing Slack integrations should be migrated manually before this feature is discontinued.
Support for Internet Explorer 11
As of Zammad version 7.0, Internet Explorer 11 is no longer supported.
Permissions for Ticket State and Priority REST-API
With the upcoming 6.3 release, we will introduce new permissions for the ticket state and priority management. It will no longer be possible to access the corresponding REST-API with "admin.object" permission. Existing roles and/or access tokens that are used for these specific REST-API endpoints need to be updated to include the new permissions ("admin.ticket_state" and "admin.ticket_priority").
Please note that you must meet the following browser requirements to use this version:
ZAA-2023-04
ZAA-2023-05
ZAA-2023-06
ZAA-2023-07
ZAA-2023-08
All improvements can be found in the Changelog.
Source code
Packages
Upgrade
Here you can find information on upgrading your Zammad installation: