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; } } }

Cloning old tickets with an amended approval step not working

Jeremy Jones_akmj1j

I have a team that clones their tickets quite often and is something I have encouraged. I have recently made a change to the approval process however I notice that any new tickets the approval step works as intended but for any cloned tickets, it just gets stuck in the approval step.

Ive included screenshots of the new step in the workflow

And the results when otherwise identical tickets are sent to the approval step. A new ticket works fine and the cloned ticket is stuck. Obviously the custom field being used is populated correctly given it works for new tickets.

Is there a setting I am missing? How can this be rectified as it is really not feasible to not utilise the "clone" function. Cloned Tickets.png New Tickets.png Approval Step.jpg

Accepted answers

All comments

Trudy P Claspill

Hello @Jeremy Jones

I see that your post has JSM tags on it. Can you confirm that this concerns a Jira Service Management project?

Is it a Team Managed project or a Company Managed project?

What is the status of the issue when it is cloned?

What is the change that you made to the approval process?

Jeremy Jones_akmj1j

Thanks for your reply @Trudy P Claspill

Our company is still switching from Jira to JSM

This particular project is a Jira Software project, however these tickets and workflows (including the approval step) are used across all projects in the company.

The status of the cloned issues is the same as the new tickets - it sits correctly in PENDING APPROVAL.

Previously the transition out of PENDING APPROVAL status was restricted to a Group of approvers

Trudy P Claspill

Is Pending Approval the initial status of an issue using this workflow?

Is the issue being cloned while in that status?

Jeremy Jones_akmj1j

Neither

The only change between old and new workflows was the approval step

Tickets start in TO DO status and are then progressed to PENDING APPROVAL.

They are be cloned post-closure so completely different status. Doing some testing, it doesnt seem to matter what status they are cloned in, if cloned at all they get stuck.

Stephen.Lugton

Hi @Jeremy Jones

It looks like there's no-one added to Change and Deployment Approvers.

That would appear to be a user picker field or a group field.

How is that populated when you create a new work item? And is it populated when you clone a work item?

Stephen.Lugton

Following on from that, did you add the Change and Deployment Approvers field when you created the approvals process? If so, does it have a value on the work items being cloned?

It's possible that your work item creation process requests that field be filled or sets it automatically, on any work items created before you added that field it will be empty, so when you clone them they will be cloned without that field filled in.

Jeremy Jones_akmj1j

This might be a possibilty @Stephen_Lugton

I will check this out - thank you for the idea

Jeremy Jones_akmj1j

I have some automation to clear certain fields when a ticket is cloned

I will add a step in this automation to ensure that the custom field is populated and see if this resolves the issue today

Is there automation steps I can implement to make sure that it ALWAYS uses the most updated default values in the field (in case the list of approvers changes over time).

This is the automation rule I am using today - unsure if it will work

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management