Custom Event Erroneous Notifications

[WD Balaban]

Some time ago it became evident that simply programmatically changing the "Assignee" w/ the relevant notification setting, i.e., "Issue Assigned = Current Assignee" does not always result in the expected notification being generated. I found a thread somewhere on this site that explained why (I suppose I could find it again if needed for this discussion). Subsequently I created a custom event, fired said event in the post functions of the transition where the assignee change is made, and modified the notification scheme accordingly. What we have discovered is that this results in spam being sent to the user that provoked the transition in addition to the new "Current Assignee". This is spam because the user is being told what he just did. The assignee change has already been made and the notification is pointless. Both user get the same notification. There are no other relevant notification settings so this is not the case of mistaken blame. Further confirmed by testing after removing the culprit custom event, i.e., no notifications occur.

This sure looks like a JIRA bug to me.

My users are complaining about spam message since when they receive the notification they presume they have a task to work, but alas this is just noise.

Anybody else seen this? Perhaps someone has a better solution to the original JIRA limitation?

Any other advise?

[Nic Brough -Adaptavist- · Accepted solution]

I'm not entirely sure where you think the bug here is.

A custom event translates to an email, determined by the notification scheme. That leads me to two questions

1) What have you got in the notification scheme that is causing the spam to go to the current assignee?

2) What does your code do? Is that actually sending the spam?

Edit - bother, hit commit too early.

I'm not saying you're wrong, or that there isn't a bug, it's just that I can't work out the mechanism for it. Jira events trigger emails to the people nominated in the notification schemes. Sending to "current user performing the action" isn't normal behaviour, and even if it was, you'd be able to remove it from the scheme.

I'd also ask if your users are using the "do NOT email me on my own changes" flag in the profiles. If they are, and you still get the emails, then it's definitely a code modification and not the Jira core causing the problem.

And, yes, there is a bug in Jira around notifications. Every action prompts a single event, and that works fine. The problem is that in some cases, we actually need TWO events fired, or at least, we need specific notifications. The "issue assigned" event has a very sensible bit of code added to it - when "assignee" is in the notification for the event, it notifies both the previous and current assignees. Other events only notify the assignee after the change - this becomes a problem when some uses "edit" or "transition" and changes the assignee - the notification to the previous assignee is missing.

[WD Balaban]

() 1) What have you got in the notification scheme that is causing the spam to go to the current assignee?

Not sure what you are asking. The spam is going to the user that is no longer the current assignee, i.e., the notification identifies the current assignee as the user that was programmatically defined in the post function before the custom event was fired. The proper notification is going to the updated Current Assignee.

In any case the only germane setting(s) in notification is the "Issue Assigneed". Complete listing is attached.

2) What does your code do? Is that actually sending the spam?

There is no custom code unless you consider Post Function settings as such, i.e., this is how the "Assignee" is changed:

First Post Function:

"The Field Assignee will take the value from CM Manager Selection."

Followed by the Custom Event

"Fire a Assignee Change event that can be processed by the listeners."

So the bug is the notification going to the user that was formerly the Current Assignee.

[WD Balaban]

The "issue assigned" event has a very sensible bit of code added to it - when "assignee" is in the notification for the event, it notifies both the previous and current assignees.

This certainly looks like the culprit. Not sure why this is "very sensible" behavior to notify the previous assignee but I presume it's not likely to change so I won't waste the time debating that.

And the "Own Changes" preference (which I was previously unaware of) would appear relevant. I'll get some help tomorrow and test this out, i.e., hard to test properly w/o at least two users.

Thanks....I think.

[Nic Brough -Adaptavist-]

Dead simple - if someone takes a piece of work off me, I want to know I shouldn't be working on it any more.

Not appropriate for everyone, I agree. I don't read my email frequently enough for it to work for me (As a generalisation, not just the assignee cases), but I work with a lot of people who do.

I think the "own changes" function will be helpful - it certainly should stop the spam of "look, I know I just reassigned that, I was the one who clicked it!"

[Nic Brough -Adaptavist-]

Ah, that's not quite what you wrote before, and it is expected behaviour:

You said " What we have discovered is that this results in spam being sent to the user that provoked the transition in addition to the new "Current Assignee".

Now, you're saying that the spam is going to the "Previous assignee". That's not a bug, that is designed behaviour, and a useful one that many sites need. As I said above, the actual bug is that the previous assignee does NOT get notified if the assignee is changed by any other method.

I suspect what you need to do is simply trigger a different event. What happens if you change the event (Temporarily of course) to "work logged"? Does the previous assignee still get it as well as the new one?

The other thing to try is reversing the order of "fire event" and "update assignee" and see if that has any effect.

[WD Balaban]

You said " What we have discovered is that this results in spam being sent to the user that provoked the transition in addition to the new "Current Assignee".

Now, you're saying that the spam is going to the "Previous assignee".

Not sure how that is different, i.e., the previsou assignee is the only user that could provoke the transition. At least in our implementations the assignee is the only user enabled to do most anything at any state in a workflow.

I suspect what you need to do is simply trigger a different event.

I considered and tried that (using the generic event) but that had no effect which makes since the event type just defines the notification email template...at least that is what is was is defined in the documentation.

I'm banking on the "Own Changes" property as the only salvation at this point. Should be able to test shortly.

[WD Balaban]

The "Own Changes" setting appears to have solved the problem.

[Nic Brough -Adaptavist-]

>Not sure how that is different, i.e., the previsou assignee is the only user that could provoke the transition.

It's very different - most workflows don't limit transitions to the previous assignee. It's useful to do it in cases, but not actually that common, in my experience, most workflows are more open than that (Even if it's just "assignee or project lead").

> The "Own Changes" setting appears to have solved the problem

Excellent! I love that flag, it kills off so much spam!

[WD Balaban]

The "Own Changes" setting appears to have solved the problem.