Change state for email reported issues
When are the mail integration post-processing commands executed? before the issue enters the workflow?
Here my case.
- I have custom workflow rules to make sure people set "Estimation" field. The rule checks this when the issue is in state <> "Submitted". I've checked the rule manually, setting the state through the ui, and it works fine.
Our default value for State field is "Open" and it has to remain like this.
- I want to keep the issues commit from email in state "Submitted".
1) I've configured the mail integration box with these comnads both in new issues and new comments input boxes:
Submitted Last message related emails ${from} ${to} ${cc}
But it seems the issue is created, then my script is evaluated and after that the post-processing command is applied.
Is it true? Any workaround?
2) I've also tried to modified the default "Collect related emails on issue creation" rule, so at the end of the action method I changed
if (newUsersEmails.length) {
issue.fields.allEmails = allRelatedEmails.concat(newUsersEmails).join(' ');
}
issue.fields.lastEmails = null;
issue.fields.State = ctx.State.Submitted;
But didn't work either, same problem, my custom rule is executed before this rule, and the state of the issue is the default value "Open".
I've found this link, but I think it won't work if I can't process the issue before it enters the so setting a tag won't help.
https://youtrack-support.jetbrains.com/hc/en-us/community/posts/360002717760-Script-order-in-workflow
Any advise? How can I tag the issues created by email before my rules is executed?
Thank you
Please sign in to leave a comment.
Hi!
I'm Sergey from the Youtrack team. Thanks for the post.
1) No, that should not be the case. The workflow rule should be triggered after the issue is created, as, well, it can't get triggered without the issue. And in this case, the issue is created after the mailbox rule's postprocessing is completed.
2) Yes, the answer you linked is still relevant.
So far, it's not clear how your rule can process an issue that doesn't exist. Still though, just in case, I've tested your scenario and not reproduced it.
If I had to guess, I'd bet that there's another rule that triggers it, which is not related to the issue's State value. I might suggest adding a log 'console.log(ctx.issue.id)' to the rule that you believe applies first to see if that's the case.
Also, you can send me the following details so I can test using them:
To share the data, you can fill in a direct request at https://youtrack-support.jetbrains.com/hc/en-us/requests/new or reply here.
Thank you for the kick answer Sergey,
We have a stand-alone deployment. Version: Build 2020.3.4313 Thu, Aug 13, 2020, 02:14:27 PM UTC
I attach the rule thats provoking the emails to stop entering the workflow.
This rules makes the "Estimation" mandatory, but it should be applied if the state is != "submitted". If I use it manually, creating an issue in state "Submitted" the guard is not triggered and the issue is created.
But if I send and email, and I push "play" button in the mailbox integration page, the message from the rule appears as Error message. (Message in spanish says "Development tasks must have an estimation")
So I think my custom rule is applied before the post-processing command is applied.
The post-processing command:
var entities = require('@jetbrains/youtrack-scripting-api/entities');
var workflow = require('@jetbrains/youtrack-scripting-api/workflow');
exports.rule = entities.Issue.onChange({
// TODO: give the rule a human-readable title
title: 'El tiempo estimado es obligatorio solo para tareas de desarrollo.',
guard: function(ctx) {
var issue = ctx.issue;
var issueFields = ctx.issue.fields;
if (!issue.summary){ // no tiene titulo
return false;
}
// console.log(issueFields)
// Si se crea en un estado != de Submitted es obligatoria la estimación
return ((issue.becomesReported || issue.fields.isChanged(ctx.State)) && issueFields.State.name != 'Submitted')
|| issue.fields.isChanged(ctx.Estimation)
|| issue.fields.isChanged(ctx.Type);
},
action: function(ctx) {
var issue = ctx.issue;
var issueFields = ctx.issue.fields;
var period = issue.fields.Estimation;
var minutes = !period ? 0 : (period.getMinutes() + 60 * (period.getHours() + 8 * period.getDays() + 56 * period.getWeeks()));
// Es tarea de explota o se convierte en tarea de explota
var isOpTask = (issueFields.Type.name == ctx.Type.Operations.name) || issueFields.becomes(ctx.Type, ctx.Type.Operations);
// console.log("isOpTask: " + isOpTask);
// console.log("minutes: " + minutes);
workflow.check(isOpTask || minutes > 0, 'Las tareas de desarrollo deben tener una estimación');
},
requirements: {
Type: {
type: entities.EnumField.fieldType,
Operations: {},
},
State: {
type: entities.State.fieldType,
Open: {}
},
Estimation: {
type: entities.Field.periodType
}
}
});
Thanks for the details. Now everything seems to be clear.
>This rules makes the "Estimation" mandatory, but it should be applied if the state is != "submitted"
Well, not really. It should be applied if the State value is not Submitted OR the Estimation field value is changed OR the Type field value is changed. So the rule makes the Estimation field mandatory if either of those is true, not only the submitted part.
I bet that you have a default value for the Type field, so it changes from null to this default value, triggering the workflow and not letting the issue creation complete as the workflow throws an error due to an empty Estimation value.
So what you should do is to remove '|| issue.fields.isChanged(ctx.Type)' from the rule's guard or use && operator instead.
If any questions appear, let me know.
Yes, you're right, removing this part of the condition prevents the rule from been triggered so I have to refactor the predicate.
issue.fields.isChanged(ctx.Type)
Thank you!
You are welcome!
Feel free to reach out if any questions appear. We'll be happy to help.