Hi all,

This problem is also being tracked at JRA-29328.

Consequently, I will proceed to close this one in favour of JRA-29328 so we can track the problem in a single issue.

Please feel free to watch/vote on JRA-29328 if you have not done so already.

Many thanks.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Interestingly enough we are having a fair bit of trouble with that one too at the moment.

Users want to receive notifications about re-assigning events only.

It can not be that hard to fix, is it?

Please check how many people signed up to watch the issue.

Our Jira users in v6.2 are restricted by this issue, too. It is hard to explain that users must activate the Assign button instead of a direct input into the assignee field to generate the important notification mails. I highly suggest Atlassian to fix this bug now (considering that it initially has been reported in 2007).

Thanks for the workaround Felix.

I'm getting very frustrated with having to install and configure add-on after add-on to cover really quite basic functionality that should be "out the box". Our configuration is getting very complicated already and I'm already getting a lot of concern from the people who are going to have to maintain and support Jira once I leave.

So, I've kept it simple and disabled the "assignee" field on the default screen, and am forcing people to use the "Assign" button instead. It's less user-friendly but a lot simpler.

ml1 I believe you could use the JJupin plugin and use its Simple Issue Language (SIL) to achieve what you are looking to do.

Essentially, you'll need to use a SIL Listener and listen for the "Issue Updated" event, then you can use the fieldHistory routine to determine if the assignee field was updated just now.

Then you can trigger an Issue Assigned event, see raiseEvent

I won't go into too much specifics here, but you've used groovy before, I'm sure you'll figure out SIL very quickly.

We have exactly the same problem. I want users to get notified when an issue is assigned to them, reagarless of whether the user has pressed the "Assign" button, or updated the "Assignee" field in the issue. It is bonkers that Jira treats these two use cases differently and fires of an "Issue Assigned" event for the first and an "Issue Updated" event for the second.

Since an "Issue Updated" event is fired whenever any issue field is updated (even "Rank, when a card is moved up/down on an agile board) it is impossible to distinguish assignments from other updates, and send a custom email.

I've been using the groovy script runner plug in to try to work around this, and even this can't manage it since the "Issue Updated" event that gets fired on an edit isn't part of a workflow transition, so you can't use a condition like issue.assignee != originalIssue.assignee

There doesn't seem to be any way to support this fundamental requirement (send email notification when something is assigned to you). This issue is now 7 years old - will Atlassian ever start listening to its users?

This problem is so insidious because most of us don't realize its not working. When I keep changing the status to 'Resolved', reassigning my tasks to the requestor and telling them to close the issue if there is no problem, I have no idea that they're not receiving any email updates. I had put it down to user stupidity/laziness until I finally realized they weren't getting updates, which made me realize that a number of updates I had taken for granted were not happening. Poor.

Unfortunately the OnDemand service doesn't allow configuration of listeners.

There is a solution for some of the use cases, with use of of listeners.

For example, JJUPIN plugin allows to do it very simple by

1. Setting up a listener for Issue Assigned, Issue Updated, etc...
2. In the listeners, fire Issue Commented, if a comment is present, by the following SIL-code

if (getComment()) {raiseEvent("Comment", key, currentUser());}

I have not tested it yet, but it seems to be a solution for the issue, when a comment is added during assignment or updating, but the event was not fired by JIRA

I agree with Max, this is a bug rather than an improvement. With the current behavior, having unique notification settings for different events is pointless and not functional, so certainly a bug.

Please escalate this and get it fixed.