Effectively using watcher filters

[ecarter]

I've been stumped about how I can effectively use watcher filters. I've created a watcher filter configured as:

- I'm the worker
- Mail events: Outgoing, Incoming and Comment
- If these criteria match: (none selected)
- Perform action: forward mail to myself

The problem I've found is that anytime the ticket changes a bucket within the same group, then I'm sent a duplicate message. There's no specific info about what bucket/group or other status is happening with the message, it appears to be just a duplicate message.

What's the best way to configure a watcher filter to avoid these duplicate messages when moving a ticket from the inbox to another bucket (like "web support") in the same group?

Ideally I'd just like to see any incoming/outgoing/comments in the helpdesk without any sort of duplicate messages.

[rmiddle]

Originally Posted by ecarter

I've been stumped about how I can effectively use watcher filters. I've created a watcher filter configured as:

- I'm the worker
- Mail events: Outgoing, Incoming and Comment
- If these criteria match: (none selected)
- Perform action: forward mail to myself

The problem I've found is that anytime the ticket changes a bucket within the same group, then I'm sent a duplicate message. There's no specific info about what bucket/group or other status is happening with the message, it appears to be just a duplicate message.

What's the best way to configure a watcher filter to avoid these duplicate messages when moving a ticket from the inbox to another bucket (like "web support") in the same group?

Ideally I'd just like to see any incoming/outgoing/comments in the helpdesk without any sort of duplicate messages.

That is an open issue. I am seeing it as well. A change in 4.3.1 seems to have made that worse for me.

Thanks
Robert

[joegeck]

Originally Posted by ecarter

I've been stumped about how I can effectively use watcher filters. I've created a watcher filter configured as:

- I'm the worker
- Mail events: Outgoing, Incoming and Comment
- If these criteria match: (none selected)
- Perform action: forward mail to myself

The problem I've found is that anytime the ticket changes a bucket within the same group, then I'm sent a duplicate message.

This one's tricky because what you are seeing is intentional design thanks to an old feature request.

[Notifcations] Enable watcher e-mails when tickets are moved to buckets by hand
http://www.wgmdev.com/jira/browse/CHD-872

The idea is workers who only watch a bucket or two need to be notified when tickets get moved into their work area. If a ticket is dropped in bucket A then moved to bucket B, the system sort of assumes workers want a notification even if they were watching A too. For someone like you who is watching entire groups this will continue to be an issue.

Originally Posted by ecarter

What's the best way to configure a watcher filter to avoid these duplicate messages when moving a ticket from the inbox to another bucket (like "web support") in the same group?

Ideally I'd just like to see any incoming/outgoing/comments in the helpdesk without any sort of duplicate messages.

I don't think there is any clean workaround unfortunately. My only recommendation would be to try and streamline your workflow. In other words, design your watchers and inbox routing rules to avoid this scenario as much possible. Could you maybe set your watchers to only keep tabs on individual buckets and limit how often you move tickets between those buckets? Or create inbox routing rules that push mail immediately to the final destination bucket, so you don't need to move by hand so often?

I do realize this won't work for environments attempting to simulate ticket escalation, so if you are in that boat...

Originally Posted by ecarter

There's no specific info about what bucket/group or other status is happening with the message, it appears to be just a duplicate message.

This on the other hand I can whole-heartedly sympathize with. If we're going to have this duplicating behavior than we should at least tell you more about the subtle differences like which bucket it came from. Would this be an acceptable solution? We may not turn off multiple watchers against the same ticket, but we could give you a better indicator of what triggered it.

I'd put in a new feature request for you, but this "idea" is already part of a much larger request asking for more customized watchers.

Custom watcher notifications
http://www.wgmdev.com/jira/browse/CHD-839

Notice my comment there about the old 3.x queue_name, I imagine if and when this gets implemented we'll update that concept to groups and buckets.

[ecarter]

Interesting, I can understand why that might be a desirable feature for some. I'll look into working with the system as is.

Just to clarify how we've been using this - in the past we've used a mailing list and the alias will send mail both to the helpdesk and the mailing list. So, any one sending mail to the helpdesk and any replies were sent to the mailing list which we could subscribe to. I was hoping to discontinue using the mailing list and utilize the watchers for this instead.

Of course, we couldn't see any outgoing mail or comments, so the watchers make a nice advantage. However, here's a few suggestions I'll submit for your consideration:

1. Optionally include a link back to the ticket in the email sent via watchers.
2. Include the option of including some sort of additional subject line flag like mailing lists (Subject: [Helpdesk][inbound #YIJ-14559-727] subject info..) so we can setup filters using Subject: [Helpdesk] instead of having to rely on inbound, outbound, etc.
3. Perhaps an additional mail event besides "Incoming" should govern the behavior of the watcher. Perhaps "Moved" or something which would distinguish between an internal helpdesk event and mail processing. When I see the word "incoming" I think of incoming mail being processed, not internal shifts of the ticket within the helpdesk.
4. Another approach to customization might be to provide a global watcher preferences pane under helpdesk setup - where people can configure the overall behavior of how the watchers operate. Not sure if that might be easier that expanding the individual customization of watchers.

Thanks, really enjoying all the improvements. I appreciate being able to participate in the evolution of this great helpdesk application.

[rmiddle]

Originally Posted by ecarter

Interesting, I can understand why that might be a desirable feature for some. I'll look into working with the system as is.

Just to clarify how we've been using this - in the past we've used a mailing list and the alias will send mail both to the helpdesk and the mailing list. So, any one sending mail to the helpdesk and any replies were sent to the mailing list which we could subscribe to. I was hoping to discontinue using the mailing list and utilize the watchers for this instead.

Of course, we couldn't see any outgoing mail or comments, so the watchers make a nice advantage. However, here's a few suggestions I'll submit for your consideration:

1. Optionally include a link back to the ticket in the email sent via watchers.
2. Include the option of including some sort of additional subject line flag like mailing lists (Subject: [Helpdesk][inbound #YIJ-14559-727] subject info..) so we can setup filters using Subject: [Helpdesk] instead of having to rely on inbound, outbound, etc.
3. Perhaps an additional mail event besides "Incoming" should govern the behavior of the watcher. Perhaps "Moved" or something which would distinguish between an internal helpdesk event and mail processing. When I see the word "incoming" I think of incoming mail being processed, not internal shifts of the ticket within the helpdesk.
4. Another approach to customization might be to provide a global watcher preferences pane under helpdesk setup - where people can configure the overall behavior of how the watchers operate. Not sure if that might be easier that expanding the individual customization of watchers.

Thanks, really enjoying all the improvements. I appreciate being able to participate in the evolution of this great helpdesk application.

ecarter,

All great idea's

With the exception of
[*]Perhaps an additional mail event besides "Incoming" should govern the behavior of the watcher. Perhaps "Moved" or something which would distinguish between an internal helpdesk event and mail processing. When I see the word "incoming" I think of incoming mail being processed, not internal shifts of the ticket within the helpdesk.

All of them have an option request on them. Joe is already working on a reply to point you to them so I wont repeat him.

Thanks
Robert

[joegeck]

Originally Posted by ecarter

Just to clarify how we've been using this - in the past we've used a mailing list and the alias will send mail both to the helpdesk and the mailing list. So, any one sending mail to the helpdesk and any replies were sent to the mailing list which we could subscribe to. I was hoping to discontinue using the mailing list and utilize the watchers for this instead.

The only other option is using RSS feeds as a way to subscribe to tickets from custom lists. Theoretically all you need to do is create a workspace filtering out all the tickets you don't want to watch and then create an RSS feed off of it. It's not for everybody but it's an additional way to monitor the Helpdesk remotely.

Originally Posted by ecarter

Of course, we couldn't see any outgoing mail or comments, so the watchers make a nice advantage.

Yea and RSS won't help you here either unfortunately.

Originally Posted by ecarter

However, here's a few suggestions I'll submit for your consideration:

Almost all of your ideas are buried in old duplicate JIRA requests that have been included in the comments of the JIRA issue I gave you last time. I linked this thread so I can easily let you know of any progress.

Custom watcher notifications
http://www.wgmdev.com/jira/browse/CHD-839

For each request, I'll give you the original JIRA items too.

Originally Posted by ecarter

1. Optionally include a link back to the ticket in the email sent via watchers.

Ticket mask URL in email?
http://www.wgmdev.com/jira/browse/CHD-1392

Originally Posted by ecarter

2. Include the option of including some sort of additional subject line flag like mailing lists (Subject: [Helpdesk][inbound #YIJ-14559-727] subject info..) so we can setup filters using Subject: [Helpdesk] instead of having to rely on inbound, outbound, etc.

Allow workers to customize the e-mail notification subject line with more information (status, etc.)
http://www.wgmdev.com/jira/browse/CHD-422

Originally Posted by ecarter

3. Perhaps an additional mail event besides "Incoming" should govern the behavior of the watcher. Perhaps "Moved" or something which would distinguish between an internal helpdesk event and mail processing. When I see the word "incoming" I think of incoming mail being processed, not internal shifts of the ticket within the helpdesk.

While the general idea may be captured in that request, it's a good standalone one too. I've created a new issue on your behalf and left a linkback.

[Watchers] "Moved" event to alleviate confusion when new incoming tickets are passed between buckets
http://www.wgmdev.com/jira/browse/CHD-1662

Originally Posted by ecarter

4. Another approach to customization might be to provide a global watcher preferences pane under helpdesk setup - where people can configure the overall behavior of how the watchers operate. Not sure if that might be easier that expanding the individual customization of watchers.

Well we already have a global watchers area in 'helpdesk setup' where you can control everyone's watchers. I imagine when we add all these new features, you'll be able to tweak them from here just like you suggested. No real need to create another JIRA item.

[rmiddle]

Originally Posted by ecarter

[*]Another approach to customization might be to provide a global watcher preferences pane under helpdesk setup - where people can configure the overall behavior of how the watchers operate. Not sure if that might be easier that expanding the individual customization of watchers.

Originally Posted by joegeck

Well we already have a global watchers area in 'helpdesk setup' where you can control everyone's watchers. I imagine when we add all these new features, you'll be able to tweak them from here just like you suggested. No real need to create another JIRA item.

I think is was asking for a kinda of general control panel to reconfigure how the watchers look instead of individual controls. Not for a central place to edit existing watchers.

Thanks
Robert

[joegeck]

Originally Posted by rmiddle

I think is was asking for a kinda of general control panel to reconfigure how the watchers look instead of individual controls. Not for a central place to edit existing watchers.

I may have not quoted it back exactly in that context, but I understand that's what he meant. Bottom line is if and when we add the kind of changes he's looking for, I'm confident there will be a way to configure them to your tastes. Most likely in the same two places they are now, 'my account' or 'helpdesk setup' (remember you can create new watchers from here too). Filing it right now is overkill since I have no idea what the interface would look like if the complementary features make it in. If there isn't a nice convenient control panel after the fact, then I'll file it for him.

[ecarter]

OK, thanks for putting stuff in JIRA. Yeah I was thinking of a control panel where you can toggle whether or not to include bucket/group transfers as part of incoming mail. Looks like I'll just need to spend more time experimenting with the watcher rules and see what seems to work best for our environment.

[joegeck]

Originally Posted by ecarter

Yeah I was thinking of a control panel where you can toggle whether or not to include bucket/group transfers as part of incoming mail. Looks like I'll just need to spend more time experimenting with the watcher rules and see what seems to work best for our environment.

Haha, it looks like Robert (rmiddle) and I may have both misunderstood exactly what you meant. Sounds like we put too much thought into it, you simply re-iterated an alternative that may accomplish the same goal. However I still think this is the better and more likely to be implemented option...

[Watchers] "Moved" event to alleviate confusion when new incoming tickets are passed between buckets
http://www.wgmdev.com/jira/browse/CHD-1662

If a "move" event is added, that'll obviously give us the solution we were after all along. And in my opinion it's even better than a simple on/off switch in the control panel to stop bucket/group transfers from counting as incoming mail.