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}.
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}.
Please sign in to leave a comment.
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.
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,
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}save template and try your use case once again.
Thank you.
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.
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}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
Thank you.
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,
Thank you for getting back to us, it's realy valuable! Great to hear this works now.
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,
Please, list notifications which are enabled for this user currently.
Thank you.
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.