Feature Request: Email Notification when Ticket Assigned

[kappy]

We need to have our techs get email notification when tickets are assigned to them, as we were able to do in 3.6.
I understand that the RSS feeds were supposed to replace this functionality, but our environment doesn't support RSS feeds, so that is not a solution for us.

[Hildy]

Well, you could tweak cerberusweb.auditlog to send email when that changes (not recommended) or add the 'ticket.property.changed' event to the listeners in cerberusweb.watchers (recommended). If you want it to be something in the mainline, then you should open a New Feature request at wgmdev.com. Community democracy plays a big part in what gets coded, so vote for it if you'd like to see it in the mainline.

[rfarnell]

I was looking for something similar, but for the bucket accounts. We have a setup of the following 3 buckets
1st line
2nd line
3rd line

I want to have an autonotification sent to a user or users who are members of that group (if they choose that notification option).

This would be most helpful.

Regards,

Rob

[joegeck]

I was looking for something similar, but for the bucket accounts. We have a setup of the following 3 buckets
1st line
2nd line
3rd line

I want to have an autonotification sent to a user or users who are members of that group (if they choose that notification option).


Hey Rob,

Not quite sure if I'm misunderstanding but as I see it this is entirely possible in the current Cerb4 Helpdesk. It might not be as stream-lined as you might like but you can do it, you just have to have each member of that group turn it on themselves.

1) As an admin make sure in 'helpdesk config->plugins' that the E-mail Notifications is on.
2) The next time a member of the group logs in have them click 'my account'.
3) In the general tab setup new E-mail Addresses to associate with their Helpdesk account.
4) After the e-mail is verified click on the 'E-mail Notifications' tab.
5) Here they can configure notification rules to forward them any new messages for a specific group/bucket.

Hope that helps!

[Maivxu]

Hi,

We had set-up v4.0 and testing it's function, so far it's good. I found this thread after trying so many time setting-up email notification to user that was assigned to that Bucket. Sad to said but it was unsuccessful. I was only able to get email notification to those user that was assigned to the Group and not to Bucket.

I followed your instruction as explained and still no luck. Is this a bug or do we have to re-config something else? Thanks - Mai

[joegeck]

Hey Mai,

This is tricky but I have a feeling the way you are trying to do notifications is the ONE way it does not work. Let me guess, you have e-mail notifications set up as I described and you have some rules in place to notify workers when new mail is sent to a specific bucket.

e.g.

Incoming mail to [Support/QA] -> forward to watcher@localhost

IF you move mail by hand to the Q/A bucket, the notification will not be sent. This rule only picks up mail that is routed to that bucket automatically through the mail parser/inbox filters.

So if you want to implement a system where you can "escalate" tickets to different levels, your best option is to simply use the last rule in e-mail notifications, where you alert a worker when he is assigned a ticket. This will remove the need for using buckets as notification bins, assuming one worker is responsible for that bucket. So the next time you set somebody as the Next Worker, he will be notified via e-mail.

However if you are using Inbox Filters to route tickets into buckets, and are still not seeing notifications from those buckets, then there is something wrong. This could be a bug that I haven't seen during our testing. Is this the case?

[Maivxu]

Joe,

Thank you for the prompt respond. The Inbox filter is working as you stated and you are correct that the bucket notification does not work when a ticket is moved by hand to an assigned bucket and that is exactly what I was trying to achieved.

Is it possible to modify it to work the way we wanted? If yes, could you please provide some instruction on how to do it? Much appreciated.

-Mai

[joegeck]

Joe,

Thank you for the prompt respond. The Inbox filter is working as you stated and you are correct that the bucket notification does not work when a ticket is moved by hand to an assigned bucket and that is exactly what I was trying to achieved.

Is it possible to modify it to work the way we wanted? If yes, could you please provide some instruction on how to do it? Much appreciated.

-Mai

I'm sure it is very possible to enable this feature into Cerb4's notification system and the developers may look to include this if there's enough demand. I went and filed this as a feature request for them to look into, once they are done with the latest milestone release.

http://www.wgmdev.com/jira/browse/CHD-872

As for a do-it-yourself solution I wouldn't be the right man to talk to. If the developers get time perhaps they'll post here in this thread, but I wouldn't hold your breath.

[Maivxu]

Thank you.

-Mai

[silas]

Can this be set as a bug not an improvement. The watcher plugin is broken in this regard. If you set it to watch for any traffic coming into a group and any responses going out it should do as it states not any tickets coming into a group via email/support center and out via any means.

[joegeck]

Can this be set as a bug not an improvement. The watcher plugin is broken in this regard. If you set it to watch for any traffic coming into a group and any responses going out it should do as it states not any tickets coming into a group via email/support center and out via any means.

You are absolutely right about the wording in the explanation. When this problem came up and I discussed it with the support staff, one of the arguments I put on the table was the need to change that language, even if we weren't going to fix the actual problem. Like you, I knew this would continue to be a point of confusion for any users who moved tickets into bucket and assumed notifications would still work.

As for changing the actual JIRA issue into a bug, I think it honestly is still an improvement for a better solution. The reason being is the way the Helpdesk currently works, this "bug" will never be completely fixed like a traditional bug would. For example what if you were to use bulk update to move 20+ tickets at once, would you expect to get 20 notifications sent out? While the answer should theoretically be Yes, flood protection and/or the resources to do that will not make that possible. This problem of course becomes worse the more tickets you move at once.

The other problem is what if you move a ticket to another bucket before the worker responds to the notification. Not only is it no longer their responsibility, but what if they don't have permissions to access that group? Technically the notification message is now outdated and useless.

I know these situations may not happen in your Helpdesk, but when you look at the big picture there are flaws in creating the ideal solution. If we start advertising "move to bucket" notifications and they don't work in all the assumed cases, then it's not going to work out.

This is why I think it's better classified as a possible improvement request to revamp the system versus a bug. If anything it's a bug simply because it's a poorly explained feature in the Notification section of the Helpdesk. It's not something we can easily fix from what I understand, so I'd hate to classify it as a bug that we *must* fix versus an improvement request that we *may* fix if possible.


In the meantime hopefully "Next Worker" notifications fill in this gap of usability as I suggested before to Maivxu. I know it's not ideal but it's the best we have currently


P.S. On a final note for people submitting bugs or concerned about how we classify issues, let me say something real quick. As odd as it sounds, improvement requests get just as much attention as bugs. So even though we will attempt to fix bugs before something else, it does not mean we disregard improvement requests. So in the long run this should get the same developer attention. You don't have to worry about it too much except for semantics.

[silas]

I would still call it a bug. Let me go through your points:

Move 20 Tickets get 20 notifications. Yes this should happen, I've worked with small ticketing systems and big and if somebody with watching a ticket or group the email needs to be sent to everybody any flood protection further down the email chain is outside the scope of the help desk but would have to be adjusted to allow for this. It's pretty common to have 10-30 person teams that would rarely get a ticket in there bucket and thus would only have email watching setup. Implementing a work schedule and auto assignment would be a work around but seems much more complex to integrate (would really need to work with external API's).

Moving to a different group, I don't know about your helpdesk but a response would be required before moving to yet another group. As to permissions etc there is no difference between this case a a new email coming into the system and generating the notification. Overall this might be an issue but it's not dependent on if you notify for a new email but not a move.

Sending emails on assignment. Sounds like a workable idea for a small shop but if you have 40+ techs that all work the same bucket it's completely unusable. Techs go to a bucket and grab the next ticket, without a lot of integration the ticketing system isn't capable of auto assigning.

The hard part of this is that it worked under 2.x and 3.x and it's what the GUI currently describes. RSS feeds seem to be a half solution via a RSS to email cludge as per notification but I'm still looking at a gap in replying via email. The code modification ('ticket.property.changed' event to the listeners in cerberusweb.watchers) looks simple enough but were now running customized code with all the maintenance issues related to them. A simple flag to implement Hildy's fix in the mainline would seem preferable.

[joegeck]

Points well taken. I understand your reasoning and agree with it, but as Q/A and not a developer I don't unfortunately make the final call on if something should be escalated to a bug, must fix, milestone, priority, etc. If I did I'd be happy to move stuff around according to community feedback. But in the end my job is to alert the developers of new issues, by reproducing them and filing them into JIRA. As a general rule I try to take the path of least resistance on filing bugs. Unless I can rule something down as an actual logic bug in the code I am not supposed to file it as a 'bug'. Similarly unless something is a complete break in expected functionality I don't give it a priority or milestone date. Trust me, I've crossed that line in the past and it only causes problems between Q/A and the developers.

If you really want to further debate this issue, you'd have to start a conversation with the developers. They do browse the forums and will no doubt see the latest posts here, if they have the time I'm sure you can get plenty more information from them.