Hi.
I don’t know if it’s a stupid idea, but it happens from time to time that the support email gets into a huge mail loop, we accomplish our tasks but then the loop continues for days or weeks with our mail in CC, but with our involvement concluded.
So I was wondering if it could be of others interest, the introduction of a new ticket state Snooze/Mute/Quiet up to a date. Follow up to the ticket shouldn’t trigger a status change (like for the pending or closed state), not before the configured date.
The “Pending till” is not usable for us as a reminder, as the Customer always resets it by answering “thank you” or “ok” or questions, you would not want to answer before the pending reminder occurs.
The function maxxer wishes is a function we also would be lucky about. Then, we could use the pending reminder function and start using the Zammad Ical Calendars.
This was so great to us, that I even would change the zammad code for it if I knew where I had to look for it.
There could be:
“Pending reminder”: Remind me at the specified date, no matter what happens with the ticket, as long as it was not closed
“Pending close”: Should work as it works. If the Customer doesnt answer, the ticket is closed. Else, it gets open.
“Wait for answer”: Should be the actual pending reminder. Remind me at the specified date, if the customer didn’t answer or any user creates content.
This request is so similar to my Persistent Reminders (just with some different naming/wording) that I’d be willing to merge my request (and its “likes”) into this one to “combine forces”. I specially like @bur’s suggestions for the naming of the three states.
Does anyonw know if it’s possible to merge feature requests?
I really wish to find a way to disable the ticket-state-disable by an answer.
I realized that, when an agent answers, ticket state always remains.
I found the file
app\models\ticket\article\resets_ticket_state.rb
there is a line:
# if sender is agent
return true if Ticket::Article::Sender.lookup(id: sender_id).name != 'Agent'
seems like the value
“ticket_article_reset_ticket_state”
has to be “true” to trigger the ticket state reset. You would have to keep it always false to not trigger the ticket state by customer answer.
But this seems to be very generic. it seems to be for:
reopening pending tickets - thats what we want to disable
reopening pending close tickets - thats a feature I would like to keep
reopening closed tickets - I dont think that the script is that for, because you can select how to react to a customer answer to closed tickets, but I would not mind disabling this, as I already disabled it with help of disgusting ticket objects and triggers.
so just always keeping the value “false” would not help in our case.
We need a kind of “if ticket.state id = pending then return false” to disable the ticket state reset on any answer.
but I am lacking ruby skills and am afraid of killing my database.
Don’t you want to be notified when a client replies? Wouldn’t you want the ticket to be re-opened? I guess I’m not seeing a scenario where this would be advantageous. Can’t think of any scenario where I’d want to do this.
That being said, I’m sure you can setup triggers for this. Perhaps create a new state called, ‘mute’. Then setup triggers for this state to stop it from being opened.
You will still be notified when a customer replies, as you always get notifications when a customer replies. I dont understand the problem.
But in most cases, we set a reminder when to contine the ticket or remind us to continue. For example, Customer orders a Computer. We order it at the distribution, the computer arrives next wednesday. I add a notice “please install Windows when the Computer arrives”, assign an agent and set reminder on next thursday. The customer has a question: “Does the Computer have 16GB RAM?”. There is no reason to reset the reminder, but it resets and nobody knows when to begin the ticket anymore. I answer “yes it has”, reset the reminder to Thursday. Customer answers “Thank you, see you next thursday” at 10pm. Next day the ticket escalates, I have to reset the reminder to Thursday. And so on.
We never needed the function to reset the reminder the last 2 years we used Zammad with over 15000 Tickets. But we have to reset the ticket states to “wait until” daily with several tickets.
We also cant use the Zammad ical Calendar, cause Notifications just disappear when a customer resets a ticket state.
Because of this, we use our Outlook Calender to plan the tickets, and ignore most escalations when the User resets the ticket state by sending questions and “ok”, “thank you” and so on.
I assume that other people use and like the ticket state reset as it is, that is okay. But as I said, for us, it was okay if that function was completely disabled for pending reminders.
No, you cant use triggers here. Believe me, I tried everything. What I could disable with triggers and objects was reopening of closed tickets, and we are lucky with it. So an “OK” or “thank you” of a customer doesnt open a new ticket or reopen the existing Ticket anymore, but we still get notified of it. Thats another thing I would want to disable without triggers, but that workaround is okay.
What if the customer wants to cancel the order? How would you know if the ticket isn’t re-opened? Don’t you want to reply to customers, or acknowledge them? I understand in some cases you wouldn’t want the status of the ticket to change; however, this can cause issues in those cases where you need it to change. Well…it would for us and perhaps that because we work on open tickets and not pending/closed ones.
I’m surprised the triggers don’t work. Perhaps that’s a bug in Zammad.
I do have issues with customers replying with “thank you” when a ticket is closed. This re-opens the ticket and I need to close it again. For myself and other agents, this really isn’t a big issue.
Even if that is possible, it sounds complex, potentially error prone and non-portable. IMHO this should better be a core Zammad functionality and not something Zammad administrators have to construct themselves (called “reinventing the wheel” )
Ha! That would make it even more important to combine these threads. As, as @MrGeneration doesn’t stop telling us, the number of “likes” is an important (although of course not the only) factor when it comes to the decision if a feature request is implemented in Zammad, three threads with few likes don’t make the same impression as one thread with many likes.
I would never use this. I’m not sure how many would, so it may not be feasible to make it a core function. If I could set it up so that a customer replying with nothing more than “Thank You” to a closed ticket, I’d probably do that. Not a global mute setting.
I imagine if this had enough support it would become a core function.
See @bur’s suggestions above (Ability to mute/snooze a ticket - #4 by bur), which suggests different “kinds” of pending states. I think that should be the direction for a core functionality, not a global “mute”.
For other kind of notifications there are the notification settings, so that you are informed about all incoming posts. There is no need to automatically reopen a ticket to be informed about a new message
If a customer wants to cancel, I will get a notification, as I already told, and will reset the ticket state on my own. Why do you think I miss any customer answers? If that saves me 5 Setting back to “Wait” a day, its okay.
The other way: Why the hell should a customer answer reset the ticket to “open”? What is the “Pending” state for, if an answer resets it all the time? I have no control about this feature.
For me, a hard disable in the zammad code was okay.
But I accept that people use this feature as it comes, and there, a new ticket state would be great.
“Please have a look at triggers and the “pending till” attribute.
This should help you to built a trigger to achieve what you want, even through I’m not recommending this approach.”
I really had a lot of looks about this. I cant imagine how to avoid Zammad from reopening pending tickets with triggers. Instead, it reopens before any trigger could work, I have no “reopened” condition and yes, I can set tickets states with triggers. But what state should I set? “Pending till” there needs a concret or relative time. I have no option “set pending state at the time it was set before the ticket state was reset”. For me, there is no trigger option to keep pending state when a customer answers. If you know anything that could help, please tell me. Maybe I misunderstood some trigger options.
Just interested, in what case do you want the pending reminder to be reset by a customer answer?
What is your intention, when you set a ticket for “pending reminder wednesday 8 PM”? I really just am interested, as I can’t imagine any sense of a state reset there.
Remember that you will get notified about every customer answer, even if the ticket state remains “pending reminder wednesday 8 PM”. You still can answer the customer on Monday, and will also get a notification on wednesday 8 PM.
This really simply comes down to workflow. For us, Pending reminder tickets are set aside and in a different overview. We don’t want to see them until the reminder comes up. We use the reminder for a few things:
Tasks that are going to be completed at a later date.
A Task that was completed; however, needs confirmation that everything is working as expected. Something that needs to be checked on in the next day or two.
Tickets that require a 3rd party to complete something before we can proceed.
As far as; “wanting the pending reminder reset”, this comes down to what do we want to do with customer updates. If a customer responds to a ticket (Whatever that response may be), we want to acknowledge that response. Sometimes it requires a reply from us, and sometimes it does not. For us, it’s simple enough to look at that response and reset the pending status.
The alternative to this is that the pending tickets stay out of our primary overviews which wouldn’t work for us.
)