Used Zammad version: 6.2.0
Used Zammad installation type: docker
Operating system: kubernetes
Browser + version: -
Provide an UI option to set default ticket state
Currently default state for new tickets has to be set in console (no docs are pointing to this)
We’ve added new ticket states as told in the docs and disabled the old (default by Zammad) states by using a filter as told in the docs.
When using the webform everything’s good
When customers create a ticket by sending mail to Zammad the ticket state getting used is still “new”
I don’t know how common this case is and towards which direction the Zammad team leans but there should be either a UI option to configure custom ticket states and set defaults for default_create and default_follow_up OR the docs should be extended to include steps how to set this.
opened 06:50AM - 06 Oct 23 UTC
closed 11:11AM - 22 Nov 23 UTC
enhancement
admin area
object manager attribute
ticket: state
### WHAT
The complexity of the choosable states of tickets is not enough for use… rs.
For example, they have too many tickets in the status "waiting for reminder” but with completely different requirements for each of the tickets and thus lose the overview or cannot perform automated processing.
Sometimes you also have other internal labels (e.g. "in progress" instead of "open").
Or after a migration from OTRS to Zammad you want to take the opportunity to improve the existing statuses by name (usually to match the Zammad standard).
**2) Which are one or two concrete situations where this problem hurts the most?**
Users want to classify tickets (e.g. "waiting for customer" or "waiting for supplier") and show the current state of a ticket.
Based on this designation, the following functions are used:
a) Overviews (e.g. "all tickets which have reached 'waiting for supplier'")
b) Automations (e.g. "all tickets which have reached "waiting for customer" should get an inquiry and the closing date should be set +1w).
**3) Why is it not solvable with the Zammad standard?**
Currently it is solvable in Zammad Standard, but via the Rails Console.
This brings two problems:
a) Self-hosted customers often lack the knowledge to issue the cryptic commands. The result is misconfigurations.
b) Hosted Customers -> Here the support (L1 and L2) is involved. There is usually some need for clarification here (between customer and L1 and then often also between L1 & L2).
3.1) Typical problems with current approach are:
In which language should the status be called what?
Where are the differences of the different status types (when do I use which one)? Which attributes do they have and when do I use which one?
What does the attribute ignore_escalation mean?
Should the state be vialable for customers too?
**4) What is your expectation/what do you want to achieve?**
Users should be able to manage ticket statuses themselves in Zammad through the admin interface.
The problems of 3.1) shall be minimized via additional support in the UI.
### Use Cases
**Use Case 1:**
Let's say I sell and deliver car parts, and use Zammad to organize my Orders.
A Customer creates a new ticket to order a part.
I notice I don't have the part currently and have to wait for the vendor.
In this case, it would be great to have a Status "waiting on vendor", since it can be confusing to label all tickets with "pending reminder" if you wait for a customer or vendor to reply. It can even have a different procedure how to Handel a ticket.
**Use Case 2:**
Let's say I am the owner of an IT company and I have an onsite technician.
A customer opens a new ticket for a hardware failure that needs to be replaced.
the agent says ok, I will dispatch an onsite technician to replace the hardware
In this case, it would be nice to have an open type status like "onsite", and the Onsite technician can close the ticket or set it back to open via the mobile Zamamd APP when he is done.
This way, you can tell the difference right away if an onsite technician or a call agent is working on the ticket.
### Intended Outcome
It should be possible to add new ticket states for different state types (e.g. pending) in the admin area. Also, it should be possible to edit existing (e.g. default ticket states) inside this section. The default ticket state type for the ticket creation and follow-ups should be configurable.
### Technical implementation
- Permission for the new admin area should be added (like we have for the other admin areas). Here we will reuse the `admin.object` permission, because it's already used in the existing ticket state controller.
- The creation of a new ticket state should be intuitive (e.g. it should be understandable which ticket state types should be used for the current use case). Maybe some description or use case examples for the field?
- The "default create" or "default follow up" selection should be on the list level (with this it's also easier to understand that only one ticket state can have this selection).
- Ticket states require the following attributes during editing:
- Name
- State Type
- Next state (= only visible for pending action)
- Active
- Ignore escalation
- Note
- Currently, the available states are fixed inside the attribute filter (because it's added inside the seeding). This needs to be updated after a ticket state was created/updated.
Clarification:
- When possible we should add a link inside the object manager attribute modal to the other admin areas.
- At which location do we want to show the new interface?
### Mockups
**Ticket State Overview**
_Ticket State Actions_
**Ticket State Add/Edit**
(For state type we could thing about some solution, to make the usage clear for the admin)
_With next state field:_
```[tasklist]
### Tasks
- [x] Adding ticket state controller handling - MM
- [x] Adding frontend for new state management - DK/TS
- [x] Adding selenium test for one user story - DK
```
You could check the development-Version, with the next release a admin interface for state and priority will be available.
1 Like