How to match stages of cloned/original issues inbetween projects that are team/company managed?

[carolina]

Hello!

I'm trying to create an automation that will automatically transition a cloned issue's status. 

Eg: I have an issue in project CSCUST (team-managed) and I cloned the issue to project DIOV3 (company-managed). When I move the issue in project CSCUST to "closed" I want the issue in project XYZ to also move to closed, and vice-versa for all stages.

This is what my rule looks like:

The stages in both projects have identical names, but the workflows are not the same, since one is a team-managed and the other is a company-managed project.

Whenever I test the automation I have an error message:

I'm almost sure that this is because of having different workflows, but I wanted to check with the community... if this is the case, how can I apply the classic JIRA workflow that DIOV3 has, to CSCUST which is team-managed??

Thank you!!

[Walter Buggenhout]

Hi @carolina,

The essential difference is that one project is team managed and the other is company managed.

Everything you say is correct. Statuses is a team managed project are available in that team managed project only. Even when you would have 2 team managed projects with statuses with exactly the same names, they are essentially different statuses.

If you want to automate the transitions between the workflows of your 2 projects in your current situation, you'd have to automate every single transition in a separate condition / corresponding action where you do not copy transition from trigger issue, but rather explicitly state transition to status X (or Y or Z or ...).

Hope this helps!

[carolina]

Right! I also thought of this and created what you mentioned already but I'm still having the same issue:

I have a feeling I'm still not applying the 2 different statuses to my rule, just the team-manages in progress status.

Do you know how can I apply the classic JIRA workflow that DIOV3 has, to CSCUST which is team-managed?

[Walter Buggenhout]

Hi @carolina,

you simply cannot apply a workflow from a company managed project to a team managed project. They are different things and not interchangeable.

You still have defined your automation rule too openly. The way you have set it up still allows any transition from any project to trigger a transition in the other and vice versa. But the different statuses cannot deal with that situation.

You basically need (at least) 2 rules: one that triggers when an issue transitions in your team managed project to then update the status of the issues in the company managed project. And then another rule that does exactly the opposite.

[Walter Buggenhout]

It is possible that you will see multiple in progress statuses in the list of available statuses, where you must select the right one (when you try to automate the transitions in your team managed project).

[carolina]

Hi @Walter Buggenhout thank you for your comments!

I was able to create an automation that was successful. See below.

The issue now is that I've copied this same rule to the other stages (closed, in progress, etc) and some work, others don't (eg, in progress) :(

I'm very confused why it works for some, but not other stages if the rule is identically built?

[Saeed Ahmad]

Yes, I also was facing that issue and I got the best results following the strategy. I solved the issue for my customer's website ( My APK House ). 

Matching the stages of cloned or original issues between projects that are team or company managed can be challenging, but here are some general steps that may help:

1. Identify the common stages or statuses of issues across all projects.

Start by identifying the stages or statuses that are common to all projects involved in the cloning or issue tracking process. This will help you establish a baseline for tracking progress and identifying any issues that may arise.

2. Define a mapping between the stages or statuses of each project.

Once you have identified the common stages or statuses across all projects, define a mapping between them. For example, if Project A uses a "To Do," "In Progress," and "Done" workflow, and Project B uses a "New," "Open," "Assigned," "In Progress," and "Resolved" workflow, you may need to map the "To Do" stage in Project A to the "New" stage in Project B, and so on.

3. Implement the mapping in your issue tracking system.

Implement the mapping between stages or statuses in your issue tracking system. This may involve creating custom fields or labels to track the status of issues across different projects, and ensuring that all team members are aware of the mapping.

4. Regularly review and update the mapping as needed.

Review and update the mapping between stages or statuses regularly to ensure that it is still accurate and relevant. As projects evolve and workflows change, you may need to adjust the mapping to ensure that all issues are being tracked correctly.

By following these general steps, you can help ensure that the stages or statuses of cloned or original issues are accurately tracked across multiple projects that are team or company managed.

[Chris Buzon]

You pretty much can't, at least not that I've been able to do.  Team managed projects are totally different from Company.  The statuses (even when called the same thing) are not the same status.

It may be possible to do this with the API, but with regular jira automation I do not think you can do it this way.

[Chris Buzon]

Walter's answer is the solution you can use it you have the time to explicitly update tickets to a team managed status.  This is a tedious process, and any changes to either workflow will require you to update the rules too.

[carolina]

Thank you! I only have 5 statuses in the workflow so it wouldn't be too much work, but I tested with one and it still not working :(