- What is your original issue/pain point you want to solve?
When I reply to a ticket article, the new draft always uses the fixed default visibility for that article type (e.g. e-mail), no matter whether the article I’m actually replying to was internal or public. Zammad doesn’t look at what I’m responding to when deciding the default visibility of my new draft — it’s a single fixed default per article type.
- Which are one or two concrete situations where this problem hurts the most?
I e-mailed an external contractor about a ticket but set that message to “internal”, because the customer must not see that this exchange is happening. The contractor’s reply naturally lands in the ticket as an internal article. When I then hit reply to continue that internal-only conversation with the contractor, my new draft defaults to “public” — the fixed default for e-mail articles — even though I’m directly replying to an internal article. If I don’t notice and switch visibility back to internal by hand every single time, the customer ends up seeing communication that was never meant for them.
- Why is it not solvable with the Zammad standard?
Zammad’s only user-facing default-visibility setting (Composer Settings in Admin) actually only controls the default visibility for internal notes. The default visibility for other article types — including e-mail, which is what this report is about — is a separate, per-article-type setting that isn’t exposed in the Admin UI at all; it can only be changed directly on the Rails console. Even there, it’s still just one fixed default per article type, with no concept of “inherit the visibility of the article I’m replying to.” On top of that, not every article type offers a reply action in the first place (some only support creating a brand-new article), so this can’t be solved by reusing the same setting across all types either. There is no standard way — UI-exposed or hidden — to make a reply inherit the visibility of the article it’s replying to.
- What is your expectation/what do you want to achieve?
When I hit reply on an article, the new draft’s default visibility should inherit the visibility of the article I’m replying to: replying to an internal article defaults the new draft to internal, replying to a public article defaults it to public. Only when starting a brand-new article that isn’t a reply to anything specific should the existing (per-article-type) default apply. This removes the manual step of re-toggling visibility on every single reply within an already-internal thread, and removes the risk of an internal conversation accidentally leaking to the customer just because the reply came up public by default. The ability to manually override visibility per article, as today, should of course remain unchanged.
If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).
Worth flagging as context: a closely related request, “Sending and forwarding internal email messages” (GitHub #3467), was already implemented back in Zammad 4.1.0 (2021) — the changelog lists it under “Implemented enhancements.” However, I’ve tested this in current Zammad (Classic UI) and confirmed replies to internal e-mail articles do NOT default to internal — they come up public. So either that 2021 fix regressed, or it only ever covered a narrower case (e.g. forwarding specifically) than plain replies. This report may effectively be re-opening/renewing that older, apparently unresolved behavior.
Your Zammad environment:
- Average concurrent agent count: N/A — submitted from a product perspective, not tied to one deployment
- Average tickets a day: N/A
- What roles/people are involved: N/A
Anything else which you think is useful to understand your use case:
This is meant as sensible default behavior, not a new configurable setting — it shouldn’t need a separate toggle, since “inherit the parent article’s visibility” is a strictly better default than one fixed value per article type, and it doesn’t take away anyone’s ability to manually change visibility on a per-article basis as before.