Placeholder for Tickets

[tjedelhauser]

Hi Ed,

when i using the E-Mail Templates feature (Settings → Email Templates → "Neues Ticket aus E-Mail") and have a few suggestions that would make it more useful:

1. Missing placeholder: direct link to the ticket

The available placeholders are [ticket_reference], [ticket_subject], [ticket_status], [ticket_priority], [requester_name], [requester_email], [analyst_name], [analyst_email], [department_name], [created_date], [closed_date] — but there's no placeholder for a clickable link straight to the ticket (e.g. [ticket_link] or [ticket_url]). Right now the requester has to search for their ticket manually instead of clicking through from the confirmation email.

2. Restrict automatic replies to certain domains/groups

Currently the auto-reply template fires for every new ticket created via email, regardless of sender. It would help to be able to scope a template to specific requester domains (e.g. only @ourcompany.com) or groups, so external senders don't receive an internal-style automatic response.

3. Configurable layout for ticket reply notifications
   For "new reply" style templates, it would be useful to define a structured layout, e.g.:

Analyst: [analyst_name]
Status: [ticket_status]

[reply_text]

My Signature

Regards
Thomas

[edmozley]

Hi @tjedelhauser, and thank you for this - all three are built and pushed.

Taking them in order.

---

1. A link straight to the ticket

There is now a [ticket_url] merge code, usable in email templates and in canned responses. It points at the requester's own view of their ticket in the self-service portal, so somebody who is not signed in lands on the portal login page with the ticket remembered and arrives where they meant to.

One thing worth setting up, because it will otherwise bite you: an emailed link needs your full web address, and most automatic email is sent when nobody is using FreeITSM. The mail collector runs on a schedule, opens the ticket and sends the acknowledgement with no browser involved, so there is nothing to work an address out from. There is now a public web address box at the top of the Email templates screen for exactly this, and if a template uses [ticket_url] while nothing is set, the screen tells you. Include the folder if FreeITSM is not at the root of your site.

The template body also has proper formatting buttons now, rather than needing HTML typed by hand. The <> button is still there if you prefer writing the markup yourself.

https://github.com/edmozley/freeitsm/wiki/Public-Web-Address

---

2. Restricting automatic replies to certain senders

Any template can now be limited to an email address, a whole domain, or several of either.

Your suggestion made me stop and think for a while, because the obvious way to build it is a rule list evaluated top to bottom, first match wins - and that asks an administrator to get the rules right and the ordering right, with nothing to tell them when the second one is wrong. So instead the most specific template wins: one naming alerts@a.com beats one naming a.com, and both beat one that goes to everyone. Dragging templates up and down cannot change what gets sent, so there is no ordering to get wrong.

A related thing turned up while doing it, which you may have hit without knowing: only one template per event has ever been used - whichever sorted first - and any others were silently ignored. If you have ever added a second template and wondered why nothing changed, that was why.

Two things guard the obvious new risk, that a sender matches nothing and hears nothing:

• Check what a sender would get on the same screen takes an address and names the template that would go back, and why. It calls the same code that will choose it for real, so it cannot disagree with reality.
• If every template for an event is restricted, the screen says so.

Neither of those helps twelve months later, when a new customer domain is taken on by somebody who never saw that screen. So an email that is not sent because nobody matched is now recorded against the ticket and in the mailbox's outbound log as Not sent, with the reason. The question "why did this customer never hear back?" now has an answer without anybody needing to remember the setup screen exists.

https://github.com/edmozley/freeitsm/wiki/Email-Template-Sender-Rules

---

3. Structured layout for reply notifications

This is the one I had to think hardest about, and I have built part of it and deliberately not built the rest.

The giveaway in your example was [reply_text]. Every other merge code pulls a fact out of the database; that one means "whatever the analyst just typed". So what you described is not really a template, it is a frame wrapped around an email somebody else is writing. That is a genuinely different thing, and it carries a risk: the analyst types into the box, presses send, and the customer receives something they never saw.

What is built: signatures. FreeITSM had none at all. Each analyst now writes their own under their name -> Preferences, with formatting and merge codes for their own details - and job title, department, phone and mobile are new fields on an analyst account, because previously there was nothing to merge but a name and an email address. You can keep more than one, for a formal sign-off and a short one, or one per language, with exactly one marked as the default.

Crucially, the signature goes into the reply editor when you open a reply, not onto the email when you press Send. You can read it, change it or delete it for that one message, and a Signature button beside Templates swaps it or removes it. What the analyst sees is what the customer gets.

What I have not built: the Analyst: / Status: header block. Those cannot work the same way, since the status has to be worked out at the moment of sending, which means the analyst would not see it. Prefixing a person's reply with two machine-generated fields also turns a personal answer into something that reads like a ticket receipt, and I do not think that is right as a default.

In practice the signature covers the part of your example that was doing the work - the sign-off, and your own details under it - so that is where I have stopped. If the header lines turn out to matter to you in daily use, open a new discussion and I will look at it properly rather than bolting it on here.

https://github.com/edmozley/freeitsm/wiki/Email-Signatures

---

There is also a guide inside the application covering all of it, under Tickets -> Help -> Settings, called Automatic emails and signatures.

One caveat: everything above is in English only at the moment. The German translations will follow - I did not want to hold the features back for them, but I have not forgotten, and I know from your earlier reports that you are using FreeITSM in German.

Thanks again. All three of these were good, specific suggestions, and the second one in particular sent me back to the drawing board in a way that improved it.