Title: configurable state display for customer
- What is your original issue/pain point you want to solve?
I need to make some states appear as a different state for the customer. - Which are one or two concrete situations where this problem hurts the most?
We’ve need a state “post processing” which would be used for example if we want to create a knowledgbase article from the corresponding ticket. But we want the customer to only be able to see this state as “closed”.
The customer doesn’t need to know if we’re actually still working on this ticket not for solving but for internal purposes. - Why is it not solvable with the Zammad standard?
A state in zammad doesn’t have an option like “present this state as … for customers” - What is your expectation/what do you want to achieve?
I’d like the possibility to use states for more use cases without making everything visible to the customer.
Currently we need to use a workaround and set an object “post processing” to true, which is invisible to the customer and only available for closed tickets.
This option would make configuration much more easy and intuitive.
mockup:
could also be titled DISPLAY (CUSTOMER) or whatever…
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).
Your Zammad environment:
- Version: 6.3.1
- Average concurrent agent count: 40
- Average tickets a day: 100
- What roles/people are involved: customer
Anything else which you think is useful to understand your use case:
There’s something similar in selection fields.
Maybe it could be even be extended, so you would have a structure like:
state_key - which the system works with
display - appearance for agents
display (customer) - appearance for customers
this way the admins could configure the state names optimized for further configuration without the need to think about what the agents/customers will see, cause it would be possible to change this without messing with already existing flowcharts or other things, that are based on the actual system-used state names.
I’m always a fan of beeing able to separate ui-configuration from system-configuration