Assignee Does Not Get an Email Notification When Ticket is Assigned to Them

[Cole]

I have a workflow setup to automatically assign tickets to particular users based on another field on creation. The assigning is working fine, but they don't receive an email like they should. 

The users have emails that link to distribution groups, so the email should be going out to a group of people. 

I have this workflow in a hidden transition that loops back to the open status, so I am unsure if that would cause some kind of issue. 

Basically my process is that on create it runs a script to look at a database to find the users location, then there is a post function that will set a custom field support group, then it transitions using the hidden transition, then there is a post function to set assignee based on the support group field.

1. Creates the issue originally.
2. Re-index an issue to keep indexes in sync with the database.
3. Fire a Issue Created event that can be processed by the listeners.
4. Jython post-function script to set location
5. The value of field SD Support Group of the current issue will be set to the result of a Groovy expression (replacing existing values).
6. Transition 131 will be triggered on the issue.

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 Generic Event event that can be processed by the listeners.
6. The value of field Assignee of the current issue will be set to the result of a Groovy expression (unless the field already has a value).

Why aren't emails being sent to the assignee when they are assigned? The assignee does get an email if I choose them as the assignee on creation manually.

Is there a better way to handle this kind of thing?

[Cole]

Thanks for the help!

[Cole]

I had the template for my new event as issue created, but set it to only a single email address. Doing this I still got two emails. I changed the template to issue assigned and it only sent one.

[David _old account_]

Oh. This is a Service Desk project, and email notifications are handled differently. I suggest you raise a support request with Atlassian Support for JSD.

[Cole]

It is the generic email that a reporter gets when they create a ticket through the portal. 

created issue email.png

[David _old account_]

Are you getting two "Issue Created" emails? If so, check the recipients of the notifications for the Issue Created event, maybe there's a mailing list in them?

Or is it another notification email?

[Cole]

I set the new Event up to only go to a single email address, a noreply, but I still get two emails as the reporter saying the ticket was received... So maybe the events are not what is causing it? I'm confused now.

[Cole]

I made a new one and it is not on my notification scheme and is inactive, however, I still get two notification emails

[David _old account_]

You can try creating a new Event type, select it in the transition, and simply not use it in your notification scheme.

[Cole]

I actually changed it from generic event to issue created event. Seems to be working how I wanted it to now, however, the reporter gets two ticket created emails because there is also an issue created event in the create transition. Is there anyway to remove or silence this create transition event? It won't let me remove it by traditional means.

[Steven F Behnke]

I second David's comment, I believe that a Transition Event will override the Issue Assigned event. 

In addition to trying David's suggestion, you could also change the Transition Event to fire the Issue Assigned event.

[David _old account_]

Hi Cole,

I believe that's because JIRA will only send every user at most one notification per transition. Maybe you can try removing the Generic Event firing at the end of the second transition.

David

[Cole]

I reordered them as you suggested. Now the assignee is getting an email notification saying the status has changed from open to open (because the hidden transition loops back to open after assigning), however, they don't get an email saying it was assigned to them.

[Steven F Behnke]

I'll copy paste your lists from above so I can be very explicit. This is how I would order the post-functions. I do not know if this is causing your issue with the event notification though, and I don't have the time to reproduce this on the spot right now.

If you are setting field data after the issue is stored, you can run into some major issues. We can reorder the post-functions and try that out.

---

Create Transition (1)

1. Creates the issue originally.
2. Jython post-function script to set location
3. The value of field SD Support Group of the current issue will be set to the result of a Groovy expression (replacing existing values)
   
4. Re-index an issue to keep indexes in sync with the database.
5. Fire a Issue Created event that can be processed by the listeners.
6. Transition 131 will be triggered on the issue.

---

Other Transition (131)

1. Set issue status to the linked status of the destination workflow step.
2. The value of field Assignee of the current issue will be set to the result of a Groovy expression (unless the field already has a value).
3. Add a comment to an issue if one is entered during a transition.
4. Update change history for an issue and store the issue in the database.
5. Re-index an issue to keep indexes in sync with the database.
6. Fire a Generic Event event that can be processed by the listeners.

[Cole]

I was thinking about that as well. So you think I should move it up to be step 3 in the second workflow?

[Steven F Behnke]

Why are you placing the post-function that updates the Assignee field so low? That may not be the problem here but I feel like that's not right.

Updates to the issue fields should happen before the Change History and Indexing occur.