Email Signatures

Email signatures

Each analyst writes their own signatures, keeps as many as they need, and marks one as the default.

Set at your name → Preferences → Email signatures.

From discussion #80, released as update #1127.

---

1. Per analyst, and only per analyst

There is no shared signature, no install-wide signature, and no administrator screen for other people's signatures. That is a decision, not an omission.

A signature is a person signing their own name. One signature for a whole team is either wrong for everybody, or it is filled in entirely by merge codes — at which point it is a template with a person's details poured into it, which is what this already is.

So every request is scoped to whoever is signed in, never to an id in the request body. Posting somebody else's signature id gets you nothing:

Attempt	Result
Read another analyst's signatures	Only your own are returned
Overwrite one by id	"That signature does not exist."
Delete one by id	deleted: false — nothing removed

That last one is worth noting: it reports honestly that nothing was deleted rather than returning a cheerful success for an operation that did nothing.

---

2. Why more than one

The obvious objection to several signatures is that choosing one becomes a decision on every single reply, and on a busy desk that is a tax paid hundreds of times a day. Worse, the failure mode is picking the wrong one and sending the casual internal sign-off to a customer.

That is why exactly one is always the Default, and the default is used without asking. An analyst who only ever wants one signature never sees a choice; deviating is a deliberate act. Several signatures then cost nothing to the people who do not want them.

The cases that justify keeping more than one are real:

• Formal for customers, short for colleagues — the same person, two registers
• One per language — FreeITSM ships 24 locales, and an analyst who answers in two of them needs two sign-offs
• Per client company — an MSP analyst replying on behalf of different customers

Your first signature becomes the default whether or not you tick the box. Otherwise you create one signature, nothing is flagged, nothing is ever used, and the feature reads as broken.

Deleting the default does not leave you with none: the first remaining signature takes over. There is deliberately no second rule promoting a replacement at delete time — one rule, applied when the question is asked, cannot disagree with itself.

---

3. My details

An analyst record held a name, an email address and a username. Nothing else. A "template driven" signature with only those two merge codes is barely worth templating — you could type them.

So job title, department, phone and mobile are now part of your account, edited in the same place, in a My details section.

They are stored on the analyst rather than borrowed from a person record. An analyst may have no person record at all, and a signature that silently loses its phone number because a link is missing is worse than one that never had it.

Your name and email address are not editable here. They identify the account, they are used to sign in and to address mail, and on an installation using LDAP or SSO they come from the directory — editing them locally would either be overwritten on the next sync or quietly diverge from it.

---

4. Merge codes

Code	Fills in
[my_name]	Your full name
[my_job_title]	Your job title
[my_department]	Your department
[my_email]	Your email address
[my_phone]	Your phone number
[my_mobile]	Your mobile number

⚠️ Why they are not the codes you already know

FreeITSM's email templates have [analyst_name]. It resolves like this:

COALESCE(o.full_name, a.full_name)     -- o = ticket owner, a = assigned analyst

That is the ticket's owner or assignee — not the person typing. It is the right answer for an automatic email about a ticket, and the wrong answer for a signature: Sam answering a ticket owned by Jo would sign it Jo, every time, to the customer, and neither of them would notice.

So signatures have their own vocabulary tied to the signed-in analyst. The my_ prefix is the whole distinction, and it reads correctly next to the account screen these are edited on. [analyst_name] keeps meaning exactly what it always meant.

A code with no value is removed

If you have not filled in a mobile number, [my_mobile] disappears rather than appearing literally. This is the opposite of what canned responses do with an unresolved code, and deliberately: an unresolved [requester_first_name] sits in an editor where an analyst reads it before sending, whereas an unfilled signature code would appear at the bottom of every email that person ever sends.

Note that surrounding punctuation is left alone. If you write [my_phone] | [my_mobile] and have no mobile, you get a trailing |. The preview shows you exactly that, so it is fixable — guessing at which separators to strip would be less predictable than showing you the truth.

---

5. The preview

The editor previews as you type, filling in your own details — including details you have typed into My details but not yet saved, so you can see a phone number take effect before committing to it.

The list of saved signatures also shows each one rendered, not raw. The point of the list is to see what actually goes out.

---

6. What does not happen yet

Nothing inserts a signature into a reply. This update is the manager: writing, storing and previewing them. Wiring the default one into the reply box is the next step, and the intended design is that it appears in the editor, visible and editable, rather than being stapled on invisibly when you press send — so that what the analyst sees is what the customer gets.

---

7. 📁 For developers

File	Role
includes/signatures.php	renderSignature(), signatureMergeData(), defaultSignatureForAnalyst(), setDefaultSignature()
api/myaccount/get_signatures.php	Signatures, profile and merge codes — session-scoped, no id input
api/myaccount/save_signature.php	Create/update; every statement paired with analyst_id
api/myaccount/delete_signature.php	Delete, scoped the same way
api/myaccount/save_profile.php	Job title, department, phone, mobile
system/preferences/index.php	The UI, alongside the other personal settings
analyst_signatures	analyst_id, name, body, is_default, display_order

Three behaviours are load-bearing:

• setDefaultSignature() clears every flag then sets one. Two statements, so "exactly one default" stays true even if an earlier write left two set.
• An empty body is judged on the text, not the markup. A cleared editor returns <p>&nbsp;</p>, which is a truthy string and would otherwise save as an empty signature.
• A missing analyst_signatures table returns no signatures rather than raising — a part-upgraded install composes replies exactly as it did before, and never shows an error in the reply box.

---

Related pages

• Limiting replies to particular senders — request 2 from the same discussion
• The public web address — request 1, and [ticket_url]
• Email Send Log — where you can see what actually went out