nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

automating move ticket from project to project

Kas Kleespie

Hello! We are trying to find a dynamic solution to automate moving a ticket from project to project WITHOUT giving access to the target project. Ideally, the agent would be prompted the same as the move feature (project, request type, issue type, etc.) but no project access. The trigger could be some field change, transition, manual etc. Has anyone tried a solution like this?

Accepted answers

Mikael Sandberg

Hi @Kas Kleespie,

Welcome to Atlassian Community!

Automation does not have a move action, nor can it change the Space via edit work item. The way we do it if a work item needs to be moved to another space is to clone the work item tho that other space, and close the original work item with a link to the copied work item.

All comments

Mikael Sandberg

Hi @Kas Kleespie,

Welcome to Atlassian Community!

Yogesh Mude_f9cg0f

@Kas Kleespie Welcome to the community!

May i ask you, what is the use case and why do you want to move it to another space where no one will be able to access those work items? Also, moving means remove from source (not copy) and move it to the destination space, in this case, why don't you create a work item directly to destination space, as anyways you are moving it from source?

Gabriela - LeanZero

Your no-access half is still open, and it's the easy bit. A rule runs as its actor, not as whoever tripped the trigger. So point the actor at an account with rights in the target space: the clone lands there fine while your agent still can't see the project. It's set in the rule's own details. That's also why automation manages this and the Move dialog can't, since the dialog runs as the human clicking it.

Before you build on the clone though, attachments don't come across. Only field values do, so the arriving ticket looks oddly bare and people notice that late. Atlassian's doc also scopes the clone route to company-managed going to company-managed, so prove it first if either end is team-managed.

The interactive part you won't get back. A rule can't stop mid-run and ask the agent for target project and request type the way the wizard does, so those decisions have to live in the rule or arrive from a field.

Kas Kleespie

We would move the item to a different project where another team is responsible for that ticket, not the original project it was requested in.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management