Cloning old tickets with an amended approval step not working

[Jeremy Jones]

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.

[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]

This might be a possibilty @Stephen_Lugton 

I will check this out - thank you for the idea

[Jeremy Jones]

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

[Jeremy Jones]

Unfortunately the above did not work with my testing

[Trudy Claspill]

There are two problems with the automation you tried.

1. You must not choose the field from the Choose fields to set list and then also specify the same fields in the JSON code. The field can be set by choosing it from the list or through the JSON code.
2. You can't plug "Default value" into the JSON code to get the field set to the default value specified in the field context.

When an issue is created by Cloning Jira does not natively copy the values in every field. It appears also that creating an issue by Cloning may not set the fields based on default values in the field context 

A workaround that you might try is an automation triggered by issue creation. Then check if the created issue is linked to another issue with the "clones" link. Then copy the value from the specified field in the source issue to the newly created issue 

[Jeremy Jones]

I have completely deleted the Default Values from the Field Configuration settings and added another automation rule that will set the approvers when the work item is transitioned to the approval status

This appears to work regardless of cloning

It does mean that management of the approvers needs to occur within the automation which is less than ideal but it works for the time being

[Trudy 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]

Thanks for your reply @Trudy 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 Claspill]

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

Is the issue being cloned while in that status?

[Jeremy Jones]

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.

[Trudy Claspill]

Hello Jeremy,

Just to make sure I'm understanding your scenario:

The approval step already existing and was working for cloned issues.
You then changed the configuration of the approval step so that the source was no longer a groups and instead became a Jira issue field.
Then the approval step stopped working for issues created by cloning existing issues.

Is that correct?

If so, then I concur with @Stephen_Lugton . You need to confirm that the field is populated in the source issue.

[Jeremy Jones]

So this could very likely be the issue

In the source issue, the approval step did not exist and therefore there was no reference to the custom field with the approvers.

The customer field does have default values so I would assume that the logic would be if the new format requires the field then it would use the default value as specified.

I think I have an idea for a workaround...