Option "Viewable" for ticket objects

ecomsilio · June 27, 2019, 11:43am

Hi all,

For each object, you can give different user rights to cutsomers and agents. There is a view, create and edit option.

But for ticket objects, the view option is missing. Can this be added somehow?

Many thanks,
Gijs

ecomsilio · July 2, 2019, 12:12pm

Is it useful to create an issue at github for this?

MrGeneration · July 2, 2019, 1:47pm

Please don’t create enhancement issues on Github.
We’ll do that as soon as we add it to our todo list.

ecomsilio · October 1, 2019, 2:08pm

Hi,

Is this feature request already on the roadmap?

Thanks,
Gijs

ecomsilio · December 7, 2019, 11:46am

Hi @MrGeneration

I just updated to Version 3.2. Thanks for all the new features
There has a lot been done to the object manager. Any change that we get the “viewable” option for tickets sometime?

Thanks a lot and have a great weekend.
Gijs

MrGeneration · December 7, 2019, 7:24pm

Sorry, I can’t provide any information on that.

system · August 17, 2020, 3:43am

This topic was automatically closed after 416 days. New replies are no longer allowed.

brigitte · August 27, 2026, 9:56pm

I went through this thread and have an even better update: this is covered today — and then some — via Core Workflows (introduced in Zammad 5.0).

Instead of a static “view” permission on the ticket object, Core Workflows let you define the ticket lifecycle as configurable states and then, for each state and each condition, control:

Which fields are shown / hidden per role (agent / customer) and per group,
Whether a field is required,
Which select options are available (e.g. limit state choices the customer sees),
What happens automatically (set fixed values, trigger side-effects).

That means the original ask — “can a customer be viewable on a ticket without edit rights?” — is solvable out of the box today: build a Core Workflow where the customer role sees a subset of fields, or a specific state type is locked into read-only behavior. And on top of that, Core Workflows also cover things the old permission scheme couldn’t express: role-based field behavior per state, per-group field visibility, enforced categorization on close, handover notes, approval workflows, …

Documentation:

Core Workflows overview: https://admin-docs.zammad.org/en/latest/system/core-workflows.html
How it works: How do they work? — Zammad Admin Documentation documentation
Learn by example (real-world recipes): https://admin-docs.zammad.org/en/latest/system/core-workflows/learn-by-example.html

So from a user’s perspective I’d consider this request resolved — and then some, since the same mechanism generalizes to a lot of other use-case patterns. Please correct me if your exact need is more specific than what Core Workflows can do today; happy to dig into it.