Link 1 ticket generated from an automation to another project, then follow the progress of the gener

Question

Good morning !

Recently, our infrastructure domain has had 2 request portals for a fire protection part (Pi), and an access control part (SALTO). Having a very specific collaboration between our two services, we wish to do the following:

* (Resolved) When a ticket is transited (SALTO), create a ticket to the other portal (Pi).
* (Unresolved) When the ticket generated at Pi is updated, commented, updated, or other, put a comment in the trigger ticket (SALTO).
* And vice versa.

How can I go about it? It's possible ?

I've done a lot of research, but I can't find anything.

Thanks in advance !

Beautiful day :)

Trudy P Claspill · Answer

What do you want the comment to say?

Will there ever be more than one clone link between a SALTO issue and a PI issue?

Both of the projects are Service Management projects. Those are typically used to manage "support" issues and enable limited communication with "customers" who are not licensed user of your Jira environment. Is that the intended use of these projects?

In Service Management projects Comments can be either Internal Only or Customer Visible. Which do you want these comments to be?

There are so many ways that an issue can be updated. Depending on what you want your comments to include you may need multiple rules to handle everything. For example:

Do you want the original value and the new value?

Single user picker fields like Reporter and Assignee: do you want the user name, account id, or email?

Multiple selection fields (list, check boxes, and fields like Request participants, Components, Labels, and Version fields) can be updated both to remove multiple values and add new values.

Links to other issues can be added and removed. What information would you hope to include about the other issues?

Child Issues can be added and removed.

An issue can be moved from one Parent to another, get a Parent for the first time, or be be disconnected from any parent.

Work can be logged against issues.

Work logs and Comments can be edited or removed.

Attachments can be added and removed.

And issue can be permanently deleted.

There is no singular Automation Rules construct that can handle all of these cases.

I think you need to take another look at your intention and think deeply about the real problem you are trying to solve, and whether or not the implementation you are considering will actually add value.

Perhaps instead of copying information between the issues, a simpler solution would be for team members in each project to Watch the issues of interest in the other project. Then the native Notification configuration could be used to send change notifications to the individuals that care about the issue. Or give each team the ability to view the issues in the other team's project.

MAURON Robin · Answer

Good morning !

Thank you for your reply !

Yes, point #1 has been resolved on my side. These are points no. 2 and 3 which are still pending.

Indeed, when I talk about "vise et versa", I mean that an update in the SALTO project should result in an update of the ticket in the PI project, and vice versa.

Regarding point #2, I thought about discerning the points I wanted to identify. However, I think it would be interesting if when a ticket (exemple : SALTO-56) is updated (whether it's a state transition, comment, edit or otherwise), it creates an internal comment in the cloned PI ticket from SALTO-56.

So, by proceeding in this way, the technicians of my team can know when the work of the PI project has evolved, thanks to a simple automatic comment. Of course, it would be the same for the other team owning the PI project.

To conclude, our company is taking these first steps into the Atlassian universe and my SALTO project is the first project of the company that will see the light of day. The PI project is the second (under development). We already have an IT HelpDesk but this was done by teams external to our company.
So, I am self-taught in this project and the administrators learn at the same time as me (knowing that my job is badge access control management, and not IT).
This is why I come directly to the community to ask my question. Because it's a brand new project in addition to my daily work.

Thanks again for your help, it’s very kind of you! :D

Beautiful day !

PS: In the appendix, a screenshot of the 2 projects to understand what I'm talking about when I talk about SALTO and PI.

I am the administrator of these 2 projects.

Trudy P Claspill · Answer

Hello @MAURON Robin

Welcome to the Atlassian community.

You can accomplish those requirements with Automation Rules.

But first we need some clarification.

What do the prefixes "(Resolved)" and "(Unresolved)" mean in points 1 and 2? Do you mean you have already solved point 1, but need help resolving point 2?

You need to describe #3 more precisely. To which of the above (1, or 2, or both 1 and 2) does "vice versa" apply? Also, what exactly is in scope when you say the Pi issue is "updated"? There are a lot of changes that could be made to an issue. Exactly which ones would you want to copy?

Jira Administrators can create Automation Rules. They may also grant that permission to additional users.

In the Automation Rules page there is a Templates tab where you may find a template that is the same as your requirement or close to it. For instance your #1 is close to this template:

Though instead of using the Clone action you might want to use the Create Issue action.

You can find more example rules here:

https://www.atlassian.com/software/jira/automation-template-library#/rule-list?systemLabelId=all&page=1&pageSize=20&sortKey=name&sortOrder=ASC

Regarding #2, in order to have changes in one issue be copied into another issue, there will have to be a way to identify the other issue. One way to do that is to have an Issue Link between the two issues. You do have to consider whether or not there might be multiple issue links between the changed issue and other issues, and then which of the other issues should be updated.

Additionally, because such a rule would be triggered by changes in one project, but updating issues in another project, the rule would have to be a multiple-project scoped rule. Only Jira Administrators can create such rules.

If you need additional information, please let us know and we can provide more detail.