Bundling changes into email notifications can break filtering

We use the subject field of our issues to filter them into the correct inbox location.

Using an example, we add [${header} ${issue.type}] into the subject template to allow us to filter new tasks, new bugs, new Features.

Our manager wants to be aware of newly created issues so he filters them into a separate high priority inbox for evaluation and re-assigning.


The problem comes when a user creates a new issue, and then instantly changes a field or assigns it to another team member. (easily done if raising the wrong priority, or missing a platform or build version)
This no longer creates a 'new bug' email, and instead creates an 'updated bug' or 'assigned bug' email.
Which then no longer enters his 'New Bugs' folder, and then goes into the 'Updated Issue' folder, which isn't checked as often.


If an issue is created and updated within the bundle time, it should always still send an email with 'New' ${header}.
11 comments
Comment actions Permalink
Hi Jim,

If just created issue was updated in less then a minute period (after creation) by reporter, these updates are not considered as 'updates' event. In this case, only one notification will be sent - on new issue created event.
I assume that it's better to take into account this rule (1 minute period) and the problem will be solved.

Thank you.
0
Comment actions Permalink
Hi Andrey :)

I've just tested this.

I created an issue, and within seconds I changed a field.
This sent a single email, and that email was an 'updated' email.

I created a second issue, and straight away changed the assignee field.
This sent a single email, and that email was an 'assigned' email.


Your description above sounds like both of my cases should have sent a 'new' email, but neither did.
We're using YouTrack 4.2.1 if that helps?

Thanks,
0
Comment actions Permalink
Jim,

You have two different cases.
For the first case, when you change some field except Assignee, please check that you have enabled 'Reported by me' - 'on issue created' notification. Currently, you receive notifications on issue updated and it's correct behavior.

For the second use case, first of all please check that you have disabled 'Assigned to me'- 'on issue created' notification. But even after that you would receive notifications with the 'assigned' in header, because this change has greater priority than other updates. That's not so obvious. To adapt it regarding your use case, please enter this code in 'Unresolved issue' notification template, in Subject field:
[${application.name}, <#if change.before?has_content>${header}<#else>New</#if>] 
Issue ${issue.getId()}: ${issue.summary} 
prettyPrint();
save template and try your use case once again.

Thank you.
0
Comment actions Permalink
Sorry Andrey, You have misunderstood my original issue report.

Both of my cases highlight the same problem.
Any issue modified within the same minute as creation should send an email with the 'New' ${header}.
Every new issue should send a new issue email.

Whether I'm receiving notifications for 'updated' or 'assigned' issues shouldn't really affect that, because the way I see it, it shouldn't be sending notifications stating an issue has been 'updated' without first sending me an email to tell me an issue has been 'created' in the first place.

I've applied your subject field template however and will let you know if this workaround helps.
0
Comment actions Permalink
Applying your suggested summary using <#if change.before?has_content>${header}<#else>New</#if> causes the summary to contain "[error]" instead of any header info at all.
0
Comment actions Permalink
Hi Jim,

Problem is the same but I've mentioned that causes of this problem are different. And those two variants should fix it.
Speaking of notifications template, please enter this code
[${application.name}, <#if change.before?has_content>${header}<#else>New</#if>] 
Issue ${issue.getId()}: ${issue.summary} 
prettyPrint();
to the Subject field. You've enetered only if-else block and it was entered in the message body.
Please, take a look at the screenshot I've attached

template.PNG


Thank you.
0
Comment actions Permalink
I must have typo'd my comment above, sorry, I did add your code to the subject (not the summary)..

I didn't enter your code word-for-word because we've already modified the subject slightly.
It's currently:
${issue.getId()}: ${issue.summary} [${application.name}, ${header} ${issue.type}, Assignee:${issue.assignee}, Product:${issue.product}]

Which I then modified to:
${issue.getId()}: ${issue.summary} [${application.name}, <#if change.before?has_content>${header}<#else>New</#if> ${issue.type}, Assignee:${issue.assignee}, Product:${issue.product}]


.. I see what I did wrong, I added that template to the default_subject, not the one for 'unresolved issues'.
I've had a few trials with that template in the unresolved subject box, and all seems to be working correctly.


Thanks for taking the time to make sure I'd done this correctly.
Feels like something that should be default to me, but this works for us for now.

Thanks again,
0
Comment actions Permalink
Jim,

Thank you for getting back to us, it's realy valuable! Great to hear this works now.
0
Comment actions Permalink
Apologies for appending to this issue, but it's a similar problem I've just been made aware of by one of our team members.

  • Assign issue to another user
  • Instantly add a work item to that

Email gets sent to assignee with the header 'updated' and not the header 'assigned'.

I'm sure you mentioned that 'assigned' gets a priority over 'updated', does this related to him enabling notifications for all available options in the project?

Thanks,
0
Comment actions Permalink
Jim,

Please, list notifications which are enabled for this user currently.

Thank you.
0
Comment actions Permalink
I've taken a look at his notifications.

The saved search in question displays only a tick on 'issue created'.
It appears he'd somehow disabled notifications for anything assigned to him.

I've just fixed this for him by making sure he's getting emails for his assigned issues.

He did put forward a valid argument that if he's ticked a box to receive an email for all created issues, he should have seen this.
But I understand our current workaround wouldn't have actually supported this.


Are you sure this isn't a bug?
User ticks "I want emails on newly created issues", but can only ensure he actually gets them all by clicking "I want all updates too"... which then means he gets a spam of mail he doesn't actually want.
0

Please sign in to leave a comment.