1) What is your original issue/pain point you want to solve?
Data protection regulations (GDPR) require that personal data is removed once it is no longer needed. Support tickets contain personal data in many places: customer reference, article bodies (e-mails with names, addresses, signatures), attachments, and the ticket history. At the same time, organizations want to keep the tickets themselves for reporting and statistics (ticket volume, close times, group workload).
Today the only options are to keep everything (non-compliant after the retention period) or to delete tickets entirely (losing all reporting data). There is no middle ground that removes the personal data but keeps the ticket shell.
2) Which are one or two concrete situations where this problem hurts the most?
- A data protection officer defines a retention period (e.g. tickets closed for more than 400 days must not contain personal data anymore). An audit finds customer e-mail addresses in old tickets — including in the ticket history.
- A customer requests deletion of their personal data (GDPR right to erasure). Deleting the user record is not enough: their name and e-mail address remain in articles and denormalized history values of all their old tickets. Deleting the tickets instead destroys the statistics for those periods.
3) Why is it not solvable with the Zammad standard?
- Zammad’s “Data Privacy” deletion task removes a user including all their tickets — reporting data is lost.
- There is no scheduled/automatic job that anonymizes tickets based on age or close date.
- History entries store old values (
value_from/value_to) as denormalized plain-text strings; they are not touched by any existing deletion or anonymization mechanism, so personal data survives there even after user deletion.
4) What is your expectation/what do you want to achieve?
A built-in, configurable anonymization for closed tickets, e.g. “anonymize tickets X days after closing”, run by the scheduler, which:
- replaces the ticket customer (and created/updated references of customer users) with the anonymous system user,
- removes or redacts the ticket articles and their attachments,
- anonymizes the ticket history completely — including
created_by,id_from/id_toand the plain-textvalue_from/value_tovalues (e.g. customer changes showing e-mail addresses), - keeps the ticket itself (number, group, state, timestamps, tags) so reporting stays intact,
- optionally deletes customer users that no longer have any non-anonymized tickets, with a per-user “exclude from deletion” flag.
–
Ticket#10231725