Replacing Zammad, importing tickets from mail server

[Mo]

Hello everybody,

as we are going to replace Zammad as Ticket server and already are using Trac for internal development since ~2016, I would like to evaluate if Trac can replace Zammad in some of the following usecases, if there are any trac-hacks towards this idea?

First I'm going to describe what Zammad is currently doing:

Importing tickets from different channels, mainly via email. That means that Zammad is listening on an customer email mailbox and creating new tickets for every new mail. Mail threads are recognized as posts to existing tickets.

Replying to a ticket is possible in an internal or public way. Public means the original channel which is email gets the message back as email.

Customers are grouped by email domain and it's possible to search for all tickets belonging to some "foocompany.org".

All the other stuff is the usual ticketing stuff, where a ticket belongs to a user (called agent in Zammad) that is responsible for a ticket, and tickets run a ticket life cycle with states and stuff, all what Trac already is made for.

Best regards,
Mo

[Martin]

On 2023-02-05 23:07, Mo wrote:
> as we are going to replace Zammad as Ticket server and already are using Trac for internal development since ~2016, I would like to evaluate if Trac can
> replace Zammad in some of the following usecases, if there are any trac-hacks towards this idea?

In my company, we went into the opposite direction: We had Trac
instances for both internal purposes and customer tickets. Because of
dissatifaction with Trac for the latter, we moved to Zammad for customer
support, while staying with Trac for internal stuff.

We used to use `email2trac` to get the emails and create Trac tickets
back then. IMHO, Zammad has better heuristics for assigning new emails
to existing tickets. With trac/email2trac, we had far too many newly
created tickets on follow-up email.

Trac, of course, has a much better web interface than Zammad and is
nicer in many ways. But for the specific task of handling support
tickets, Zammad has advantages, I missed in Trac.

I'm curious: Why do you want to move away from Zammad?

Cheers

[Mo]

Martin schrieb am Montag, 6. Februar 2023 um 10:25:29 UTC+1:

I'm curious: Why do you want to move away from Zammad?

Hi Martin,

actually I can confirm what you said about Zammad having some advantage on tracking customer tickets. For instance it is quite good to track replies referencing the same ticket without creating new tickets on every reply.

For this reason we had Zammad for customer emails and Trac for internal use.

But recently the Zammad 3.4.0 to 5.3.0 migration became a nightmare: https://community.zammad.org/t/migrating-3-4-0-to-5-3-0/10462/9

While even simple 3.4 to 3.6 migration was failing on database issues and appearently only a few developers supporting there on the forum.

We might end up just using a fresh Zammad installation without doing the data migration, but that kind of lacking community support is risky for future updates. So beside that I'm already looking for alternative opportunities.

I know also the Trac community is small, with a few developers only. But actually I got all isues solved with all your support over the last years (thanks for that) and the Trac project still looks like being alive.

BR.