Customize ticket view to show reply and hide notes fields


  • Used Zammad version: 3.5.x
  • Used Zammad installation source: (source, package, …) Ubuntu Deb
  • Operating system: Ubuntu 20.04
  • Browser + version: Chrome 86

Expected behavior:

  • when opening a ticket, there is no need to click on reply or reply all, but a textbox appears with this functionality instead of notes

Actual behavior:

  • notes appear and I need to click on reply before I can submit replies

Steps to reproduce the behavior:

  • open a ticket

I am seeking for a configuration or CLI command which I can use to set the default look and feel of the UI. Understanding that many organizations may want to use notes before replying to the customers, we use notes less often and want to directly answer tickets. A view showing the textboxes of reply instantly in the ticket view would make our work more efficient. Is there an option or command, or skin we can use to change the default ticket view?

1 Like

What you’re trying to achieve is not possible.

here’s why:
In Zammad you can have a communication with several parties within the same ticket.
Pressing “reply” or “reply all” will decide on who you’ll reply.

People tend to bring in new parties to a communication or remove them later on.
If Zammad would work the way you suggest, you’d have no power over this any longer.

while understanding the technical side and the reason why it is as it is - we recently got asked by clients why theire ticket(s) have not been answered.
The reason is simple: From time to time colleagues do not click on “reply” but instantly write into the “notes” field.

So - our most important function (“reply”) is one of the smallest click areas which are present in the Ticket view.

Our problem therefore is less technical but more kind of a UI topic.

EDIT: Just found this issue on Github "Reply" action in UI unclear · Issue #372 · zammad/zammad · GitHub
It describes exactly our problem: EVERY single user expected the notes field to be the “answer area” to create an email response to the client.
Besides that, the “Aktualisieren” Button in the right bottom hardly ever have been identified as “send” button.

Just to be clear: This is not a question of low priority. This “little problem” is anoying as f*** - first only for the users, later on for our clients waiting for answers and finally for everyone.
I simply have to argue and justify my decision for zammad more and more often. I’m still convinced I made the right choice, you all did and of course still do a great job!

I get your point, still, it’s nothing I can just change.
We have an issue for it as you found out, so it will be dealt with in the future.

A side note regarding article fields not being clear - a current 3.6 is telling you that you’re writing a note before clicking:

My unpopular opinion:
This is a training issue. See above screenshot, it’s literally standing there what’s going to happen.

Beside, if your agents tend to do above mentioned, you could fail safe that with a trigger if you have to.
That’s no real solution in UI terms, but will solve your issue on a short term: Your agents “seeming” not to answer your customers.

That is because the update button technically (and by fact) is not a mere “send” button.
It does update the whole ticket - everything that is a draft in that moment.

Our documentation should be able to help further too, it does cover those aspects:

1 Like

Thanks for your answer and I do get your points as well. Anyway, your arguments are still from a very technical view.

From a Usability view it’s pretty simple. If more than half of the users (actually around 90%) would use it wrong without training, it’s not the users fault.

I’m ok with your answer and I really hope you deal in a user and usabilty-friendly way with that issue. I’m sure zammad is on a really good path and already one of the very best help-desk systems. UI issues like that are the key to the users acceptance.

thanks and have a nice day!

I really don’t want to be the ass hole here, but this seems to be a specific issue in your company maybe.
We have dozens of users that are fine with the UI.

What I actually wanna say:
We’ll probably never reach a point in terms of UI were we will make every one happy.

For now you could use custom css for your reply buttons to be more fancy and noticable as they are now. Even though this is not update safe exactly, it could also help to cure your issues a bit.

1 Like

We ran into the same issue. I know others who ran into it, too.

The main problem is that Zammad UI looks like a chat. People tend to just type replies in the text field on the button like on every other chat tool. But Zammad behaves different and people are not aware of it.

Instead of a text field it would be nice to have a button for a note.

We’ll probably never reach a point in terms of UI were we will make every one happy.

Maybe you can make it configurable? So many people hit the issue that something has to be done on the long run.

I am open to pay for the development.

We try to keep the configuration as simple as possible. We don’t want to end up like other big (old) competitors where you need 3 years of study to flip a switch without fire.

Any way.
If you believe your approach would be benefital and are sure we’ll have the same perspective you can try to get a feature sponsoring (so you pay for the core function and it will become core). If that won’t work you’d also have the option for a custom development.

I can’t decide which way is correct for you. If it’s not too urgend you could also try to post a feature request here and get a lot of hearts on your first article (this helps us to see the demand).

No matter how you decide, you could drop a mail to sales [at] zammad [dot] com to see if there’s a way for both sites.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.