vcvc

Please note that as of JIRA 4.4 any properties would need to be set in jira-config.properties or jpm.xml.
Unfortunetaly both ways don't work for jira.assignee.change.is.sent.to.both.parties=false
See: https://jira.atlassian.com/browse/JRA-25926

I agree with Bob. "Previous Assignee" would be the right thing.

While searching for a plugin to solve my problem I found We Engineer - Custom Field Types which can be used to see previous assignees and send notification to them using notification scheme.

Not sure whether this plugin relates to this issue or not. Just wanted to share with you all.

I know this issue is already resolved, but, just ran into this with our JIRA 4.0 upgrade. Going to use the property provided to revert to old behavior to reduce the notifications. While I agree the new behavior (notify both) is better in most cases, I don't think the solution was the right approach given the incompatibility and idea of a notification scheme to control behavior. For me the proper solution would be to add Previous assignee to the list of notification users/groups and the Add notifiction screen to go with the existing Current assignee. That way I can set up the notifications they way I want as opposed to discussions and arguments about what is the expected way. Certainly the current wording on the screen of Current assignee is now wrong or at least misleading. In our case, we need some projects to not notify previous and other projects to notify previous.

We cannot generate 2 events for a change as this will break a lot of existing IssueListeners. To implement a fix for JRA-12362 we would need to change how the Notification sub-system deals with generated events rather than generate multiple events. The notification sub-system would need to allow one to e-mail a certain set of users whenever a particular field is changed, no matter what operation has been performed.

This bug should not have been tracking requests for those changes. Referring you to this bug was a mistake. Please accept my apologies for this. I am hoping that not too many people have been led down this wrong path.

I am sure there are people who will benefit from the actual bug fix that has now been committed, and therefore we would like to resolve this issue.

Cheers,
Anton

Now whenever an the assignee og an issue changes then the previous assignee will be notified as well.

For those people who do not like this new behavior there is a new jira-applications property to revert to the old behavior.

jira.assignee.change.is.sent.to.both.parties=false

Just to be clear, whenever we've reported this problem, over the years, whether via support or forum, we'd been asked to vote on this issue. i would rather you create a new issue to fix whatever it is you're planning for 4.0 and keep this issue open to address the problem of not notifying new assignees of issues assigned to them via edits.

The problem with starting a new voting track on another issue is that it hides the fact that this bug has been around forever, and that as admins, we've had to remove Assignee from our edit screens to work around it.

And Anton, while I understand that firing 2 events is non standard, so is the concept of sending a notification to 2 people (old and new assignee) on one event. Therefore, the precedent has already been set to acknowledge that assigning an issue is a different kinf of update from any other, and merits special code paths.

I've re-voted on JRA-12362 as well. If anyone else is watching this issue I suggest you do the same.

Thanks Anton and Neal for keeping this one alive.