Plugin assigns user but email notification doesn't say assignee changed

[Kalen Brown]

I setup the workflow to assign an issue to someone from a custom field as part of the post function (per the plugin mentioned below). The new assignee receives a email that says the fields that have changed (EXCEPT that the assignee field change is not included in the email) and a notice that the field was updated but the email they receive does not relay to that person that the issue has been assigned to them. Even though the assignee field has changed, that is not included in the email. Thus the new assignee never knows that the issue is in their hands unless the open the JIRA webpage. I think the plugin is creating an extra "event" as shown by the history where the assignment is not grouped in the same "event" in the history as the transition. Whereas the non-plugin method groups them properly.

Speculation: This "extra event" that the plugin performs is done under a sort of "suppress notifications" time span while the post functions run so that only one notification is sent. but the assignment change is a self contained event that does not get rolled into the transition notification. It would be desirable to have the assignment change be rolled into the existing notification email that the transition was executed and other fields have been updated, but if that is not possible the a separate email would be needed. Two emails to all watchers on each transition would be cumbersome, so I think the user would have to setup a custom event, to fire after the plugin completes the assignment, that would only notify the assignee that the issue was assigned to them.

I discussed the issue with Atlassian here https://support.atlassian.com/servicedesk/customer/portal/22/JSP-253730 but I don't think that is visible to the public so I will summarize below:
I asked them about the location of the custom post function with respect to the order of the native post functions. Atlassian said that the order of the post function really matters and that I shouldn't mess with the order of the post function. However, in my troubleshooting I tested the post function as the first, last, and the original location that it puts it in and found no difference in how it affected the issue. So the order of the post function did not change the outcome.

Per Atlassian request, I used the JIRA native post-function ("Assign the issue to the reporter") for both "Resolve" and "Reopen" transitions and I set all other transitions to clear the assignee field (for testing). Upon using the Resolve and Reopen transitions, the email sent to me shows that the assignee field was changed. Also, in the log, the transition and the assignment change always appeared as the same log. As opposed to being in separate log entries as was shown with the plugin.

Workaround: Change the post function "fire event" to assigned rather than the generic.  This seems to be the best option.  In workflow transitions that utilize the "Issue will be assigned to the value of XXXXX Customfield." post function, fire a "Issue Assigned" event that can be processed by listeners.", or some event that forces the email notification to post the assignee, rather than a generic event.  This event forces the words "assigned an issue to " at the top of the email and will paste the contents of the assignee field even if the assignee field was purged/cleared.  In the cleared case, the text after "assigned an issue to " will just be blank.

Resolve issue with Assign to Customfield plugin post function using fire event Issue Assigned post function .PNGResolve issue with Assign to customfield that is empty plugin post function using fire Issue Assigned post function event .PNG

JIRA Email assign to custom field with using plugin.PNGJIRA Email assign to reporter without using plugin 2.PNG

Since it won't let me comment on Phill's post until after 24 hours, I will temporarily add my response here:

"

Thanks Phill,

the question that I had the link to was specifically about the order of the post functions. They, and you, reassured my initial assumptions about the individual post functions and the order of them around custom functions.

I added two attachments to my OP that show that the plugin related post function "Issue will be assigned to XX customfield" was the first post function in the list. I test placing this at the beginning, the original location, as the LAST post function (after update history, Re-index, and fire event). This resulted in no visible change in the way the issue was worked with. The assignee field was updated regardless of the location of the post function.

"

Environment:

Atlassian JIRA Project Management Software (v6.4.3#64018-sha1:4550402)

Issue Alternative Assignee

Version 1.7.8

Vendor:

Vendor: Jamie Echlin

Add-on key:

Add-on key: com.iamhuy.jira.plugin.issue-alternative-assignee

JIRA Email assign to custom field with using plugin.PNG

JIRA Email assign to reporter without using plugin 2.PNG

Resolve issue with Assign to customfield that is empty plugin post function using fire Issue Assigned post function event .PNG

Resolve issue with Assign to Customfield plugin post function using fire event Issue Assigned post function .PNG

[Phill Fox]

Hi Kalen,

I can provide you with an explanation as to what happens with the post-functions and why the placement of your post-function is so crucial.

1. Set issue status to the linked status of the destination workflow step.
2. Add a comment to an issue if one is entered during a transition.
3. Update change history for an issue and store the issue in the database.
4. Re-index an issue to keep indexes in sync with the database.
5. Fire a Issue Resolved event that can be processed by the listeners.

If we consider where your post-function sits in this list we can then know what information is available to the email notification.

Before 1, 2 or 3. 

Your update to the assignee should be held in the working copy of the issue attributes.

After 3

The issue has already been updated with the details from the working copy and so your change will not be captured.

Step 4 then indexes your changes to retain them correct in the database.

Step 5 is the point at which the Issue Resolved event is triggered. As you have seen the different events send different emails. You can create a new event and associate this with the transition of your workflow.

You can also define new email templates. However, be aware that editing the email templates to bring additional detail in to the email requires access to the hosting environment to change these templates. https://confluence.atlassian.com/jira/customizing-email-content-185729653.html has instructions and remember to change both the HTML and text versions of the email template. To change the subject line you need to edit content in the subject folder.

Whilst not completely answering your question I hope this has helped explain what should be happening.

Phill