Title: Hide non-addressable users from the To/Cc recipient autocomplete
- What is your original issue/pain point you want to solve?
In the To/Cc recipient fields of an email article, the autocomplete offers
entries that cannot actually become recipients.
Two cases:
- Users with no email address are listed. Selecting one does nothing at all:
no token is inserted, no error, no feedback. The agent is left wondering
whether the click registered. - Inactive users are listed with strikethrough and are fully selectable.
So the list and the set of valid recipients are not the same set, and the
agent only discovers the difference by clicking.
Important scoping note: I am asking for this in the To/Cc recipient context
only, not for user search in general. A customer without an email address is
perfectly legitimate (created over the phone, or imported before a directory
sync populates the mail attribute), and inactive customers must stay visible
in the Customer field so that historical tickets remain navigable. Those two
contexts have opposite requirements, which is why I am not asking to change
the underlying user search.
- Which are one or two concrete situations where this problem hurts the most?
We run the IT helpdesk of a municipal administration: 30 agents, roughly
2000 internal customers, mail-centric workflow.
Situation A — privileged accounts. Our admin accounts are separate,
privileged accounts, held by the same people who also have a regular agent
account. No account holds both roles. We deliberately cleared the email
address on the admin accounts, precisely so they can never receive helpdesk
correspondence. They nevertheless appear in the recipient dropdown whenever
an agent types a colleague’s surname, immediately next to that colleague’s
real account, and the two entries look almost identical. Agents pick the
wrong one, nothing happens, they retype. It is a small friction repeated many
times a day, and it slowly erodes confidence in the field.
Situation B — former employees. In an organisation of this size there is a
steady turnover. We set departed users to inactive rather than deleting them,
to preserve ticket history. Their accounts stay in the recipient list,
struck through but selectable, competing with active colleagues who have
similar or identical surnames. An agent in a hurry can send a reply to a
mailbox that no longer exists, and the bounce comes back into the helpdesk as
a new ticket.
- Why is it not solvable with the Zammad standard?
There is no setting that influences which users the recipient autocomplete
returns.
- Deactivating the user does not remove it from the list.
- Clearing the email address prevents selection but not display, which is
where the confusing half-state comes from. - Core Workflows operate on select fields and have no effect on user search
fields. - Renaming privileged accounts to something non-nominative (so they never
match a surname search) does work as a workaround, but it conflicts with
the auditability requirements of a public administration, where a
privileged account must remain traceable to a named individual.
The only real alternative left is patching the search backend, which is not
something we want to carry across upgrades.
- What is your expectation/what do you want to achieve?
The recipient autocomplete should only offer entries that can actually
become a recipient. Concretely:
- A user with an empty email address is not listed in To/Cc.
- An inactive user is not listed in To/Cc.
- The Customer field and general user search are unchanged. Both cases stay
visible there. - Free-text entry of an arbitrary email address keeps working as it does
today.
I would consider this fixed if the rule were simply hardcoded for the
recipient context; I am not asking for a configuration option. If you prefer
it to be configurable, a single setting such as “recipient autocomplete:
only show addressable users” defaulting to yes would be fine too.
If the current behaviour for inactive users is intentional (e.g. so agents
can see that a former recipient existed), an acceptable middle ground would
be to keep them listed but make them non-selectable, consistent with how
users without an email address behave today. The half-state where an entry
is clickable but silently does nothing is the part that is hard to defend to
users.
Your Zammad environment:
- Average concurrent agent count: 30
- Average tickets a day: 200
- What roles/people are involved: agents (30) and customers (2000)
Anything else which you think is useful to understand your use case:
Installation type: package, Ubuntu. Zammad version .
Our customers interact with the helpdesk exclusively by email, so the To/Cc
fields are the single most used control in the whole interface. Anything
that adds ambiguity there is amplified by volume.
Our role separation is strict and, I suspect, not unusual in public sector
deployments: privileged accounts on one side, agent accounts on the other,
with no overlap. That separation is what surfaces this behaviour so often
for us. Organisations where admins are also agents would probably never
notice it.
Thank you.