Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,559,491
Community Members
 
Community Events
184
Community Groups

Automation rule Move ticket to another project

Edited

automation that moves tickets from one project to another project. You need to use JSM Playground and R&D Assistant project.

Keep in mind when the ticket is moved it should keep the reporter and request participant the same. There is no need to move the assignee.

1 answer

1 accepted

0 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Jun 22, 2022

Automation does not have a function to move issues between projects.

Moving an issue is a complex process that changes the structure of an issue, and as such, you have to check that it is possibble, and usually ask the user to add or amend data on it, and confirm that they understand some data may be lost.

It should never be part of a process, and it should never be automated.  It is for genuine mistakes and housekeeping/re-organising.

Hi  @Nic Brough -Adaptavist-, I understand your point, but there are use cases where intake is controlled and thus it would be desirable to be able to automate moving tickets.  In our use case, we're trying to build a single point of contact/intake project for a team that interacts across the entire company, then move tickets with clear destination locations to their respective boards using rule automation.

We're currently building it as a team-managed project (but it could easily be changed to company-managed, that just places more burden on our company admins).  We have the issue type forms designed to mirror the field values of the desired project, so we should conceptually be able to move the tickets with no errors or issues, because we control what's collected. 

I understand that there is a risk that a change made in the destination board that isn't made in the project with automation could cause issues, but as long as it failed safely (i.e. the ticket was created but not moved, with a noted error message), I don't see why that wouldn't be an acceptable outcome.  Right now, we're having to use the "clone" feature instead, which has the same issue/outcome (error if the fields don't map), but creates 2x as many tickets (and fails poorly, in that it just ignores the "Clone" step).  Since create is separate from move, it seems like the ticket shouldn't be lost, even if the "Move" step fails, so it doesn't seem all that different than "Clone".  Perhaps I'm missing something though.

 

NOTE TO EDIT: Since JIRA Cloud also permits adding fields from company-managed projects to team-managed projects, the one risk I mentioned isn't even an issue when that occurs, so permitting automated CLONE but not permitting automated MOVE makes even less sense when destination project fields are used.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Feb 03, 2023

<grumpy-Nic mode on>

No., there is never a case where moving a support issue to a development issue is right.

In Jira, this will destroy the customer request, it makes it look like you have deleted the request they have raised, and destroyed the communication channel with them.  You are doing absolutely the right thing in saying "the developers need to do something with this", but failing your customers by "deleting" their issues.

<grumpy-Nic mode off>

Please, use "create linked issue", not try to clone and dissociate, or move.  You do not need to worry about fields or anything else if you use that.

Hi @Nic Brough -Adaptavist-, the use case I mentioned isn't a "support to development" concept, for clarity, it's just a central intake board for different types of requests that (for a few use cases) we move/clone tickets to correct boards. 

While it would be nice to be able to just tell users "go to such and such board" for a particular ticket type, they don't always know that's where they should go, especially if it's a board with which they maybe need to interact only once a year (e.g. reporting a product vulnerability).  I will read up further on "create linked issue" though, per your feedback.

We have already identified a configuration that I believe will enable us to do what we need, I just was stating my opinion that there doesn't seem to be much of a difference between moving and cloning re: the complexities that need to be addressed (e.g. required fields addressed), so it didn't make sense to me that the system permitted automating one but not the other.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Feb 04, 2023

So the question there is why you have set up a system where people are not directed to the right place to raise things.

It makes perfect sense to not be able to automate things that should not be done automatically!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events