Jira automation failures

[Iryna]

I have been using automation to create linked issues in multiple jira boards based on a custom field value. My scenario is following: one team starts working on a ticket, and once they are done with their part, other teams (multiple teams) will need to do their part accordingly. 

So I have a board where the workflow starts, then at certain status, the jira automation triggers creation of linked issues in other teams boards based on Implementation team fields. 

It worked fine when I just implemented it (couple of weeks ago), but now the rules just fail for some 1 or 2 out of very identical 6 rules. The only thing I could think of is potential problems when the ticket has 2 or more implementation teams selected, but it works half of the times. Very confusing. 

Attaching some screenshots with my rules, happy to answer more clarifying questions. 

This rule always works:

this rule fails with error: Can't create the issue in project ( I checked all permissions and such). what else could be wrong here?

[Iryna]

thanks both for trying to help. The issue type = Task that exists in all projects. the only statuses that rule runs from are Todo or In Progress. Which exist on all projects. 

I am out of ideas honestly, cause I explained earlier that i have 6 identical rules, and 1 or 2 fail every time, while 4 -5 work. And it is not the same rules that are failing every time.  here is a screenshot from earlier today. 

[Iryna]

if you see my first screenshot from this thread - the rule that was failing was called - event implementation (VC ios Israel) and it is successfully run today with no changes made since last time. 

[John Funk]

I still think there is something different about the issue. Maybe there is a required field in the target project that is sometimes not populated?

[wwalser]

John is asking many of the same questions that I would ask. To avoid polluting his answer thread, I'll start a new one for my own questions.

I hasten to add that I won't be able to dig deep into specifics in a community question. Support is a better format for that discussion. That said, I'm happy to share information that may be generally useful when debugging this category of issue.

Check the project type. Specifically, if any of the projects (origin or target) are "Next-gen" projects, that could be the culprit. Unlike Classic projects, Next Gen projects do not re-use most resources across projects. Instead, they create entirely new versions of many of their resources (issue types, workflows, screens). This was done to reduce configuration complexity. Schemes are often confusing to new people new to Jira.

Whie this duplication reduces the configuration complexity, it does cause issues when attempting to automate issues across multiple projects as all of those once shares resources are now distinct entities and it's difficult to know when they should be treated as the same. We're actively working on improving automation in Next Gen.

In the error from the screenshot above:

> can not create issue in project/issue type 13850/11441

13850 is the project id.

and 11441 is the issue type id. 

Similar to John, I'd be curious to know if that issue type exists on the target project. You could check that in Jira's preferences, or hit the REST API https://stagingwatergood.jira-dev.com/rest/api/3/project/13850?properties=issueTypes and see of one of the listed issue type IDs is 11441. 

[John Funk]

Hi Iryna,

Can you post a screenshot of the error you see in the Audit Log for the rule? 

[Iryna]

see attached 

[John Funk]

Are you sure all of the permissions are there? Take a look at the Create Issue permission in the permission scheme for VCANDROID and compare it to the permission scheme for MI.

[John Funk]

Make sure that Project Role (atlassian-addons-project-access) has Create issue permissions. 

[Iryna]

I don't think permission is  an issue, I even granted the Reporter of the ticket an admin permissions to all the projects. 

I have a different rule that was successful at creating tickets in that failing project, see attached. 

I was trying out the different approach where instead of cloning twice within the same rule, I had two separate rules as an experiment. While that experiment worked for some time, the different rule (identical one) started failing. 

So I am having 1 or 2 rules out of 6 fail consistently. 

[John Funk]

Ah just noticed that the above error you mentioned also mentioned issue type. So make sure that the issue type is available in the MI project - the issue type used in BPO-207. 

[Iryna]

I did, it’s a type Task that’s available in all projects. 

[John Funk]

Does that issue type use a different workflow in the two projects? 

[Iryna]

yes it does. 

But it wouldn't explain why i can create tickets in that project with a different rule, but not the original one. If you see the last screenshot I attached yesterday, it is the same project that in a rule with an error. 

My original rule tries to create clones in 2 projects (it does always create successfully in one of the projects (android), but fails for another (magisto ios)). I had to make a different rule that only createsa clone ticket in a magisto ios project, and that rule doesn't fail.

Why does the rule1 fail? 

[John Funk]

It might be because you are cloning a ticket that is in a status that doesn’t exist in the target workflow. I have seen that already this week in another post. 
So there are a lot more fields getting cloned other than just the project. 
I suspect it is the status.

[Iryna]

I only clone tickets when status hits In Progress in a workflow, which exists in both of the projects. Do workflows have to completely match? 

[John Funk]

No they don't have to completely match, but the value being inserted at issue create time must match. The other thing is to match every field between the two issues when you cloning in those instances where it fails. Something has to be different. 

If you can't find it or unwilling to go to that effort, then you probably need to go ahead and submit a Support Ticket with Atlassian. 

[Iryna]

" but the value being inserted at issue create time must match" - what do you mean by that?

[John Funk]

The current status in the first issue must be available in the workflow of the cloned issues.