Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Ensuring all the required fields when cloning a ticket

Matthew Valley January 28, 2025

I am trying to setup a workflow that accomplishes the following:

1. User submits a Form that is attached to a Service Request Ticket.  

2. An automation clones the Service Request Ticket into a Software Ticket, inheriting all fields

However, when I test this workflow by filling out a new form, the ticket cloning fails with the following message:

 

'Unable to create issue
XXXXX is required. (customfield_12345)
Issue was created successfully, however some unexpected errors occurred -'
In this case XXXXX is a customfield that is populated in the Form.  
The error message is possibly telling me to COPY this field in the cloning automation, which I have tried, however, this doesn't change the error.  
Please help me interpret this error, and better understand how to ensure that all required fields are present to properly clone a ticket.

3 answers

0 votes
Marcos Defina
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 29, 2025

As answered under @Marc - Devoteam thread, the problem seems to be a typo on your  advanced fields JSON.

Having double underscore in between customfield and its id 12657 is causing the failure, as the instance can't understand where to put that information as a customfield__12675 is unlikely to exist, and the required field customfield_12657 which is mandatory field isn't being populated -> causing the failure on creating issue.

I hope that solves the problem.

Bests,
Marcos Defina.

0 votes
Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 28, 2025

Hi @Matthew Valley 

Welcome to the community.

You should be able to fix this by adding the field under More Options, advanced editing options via JSON.

Following as an example:

 {
"fields":
{
"customfield_12345":"{{issue.customfield_12345}}"
}
}

Matthew Valley January 28, 2025

Thanks for this suggestion! 

The clone operation already has some JSON code, here it is with the addition of your code above:

Screenshot 2025-01-28 at 17.18.00.png

I've placed your code snippet where I gather it belongs based on this article.

However, my error message now reads: 

Screenshot 2025-01-28 at 17.05.27.png

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 29, 2025

HI @Matthew Valley 

Is the field available on the other project?

And is the rule scoped for both projects?

Marcos Defina
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 29, 2025

Why the double underscores? seems like this is the problem - your Project Code customfield is required, but you're given something the instance doesn't understand customfield__12657.

Fix the typo, and most likely it will work!

Like Marc - Devoteam likes this
0 votes
Marcos Defina
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 28, 2025

Hi @Matthew Valley

Welcome to Atlassian community!

 

In order to ensure all fields are submitted to the issue creation, you should make them mandatory in the form software you're using.

Once the form is submitted, if there is anything missing, and you enforce the needs of such fields on jira side, all that will happen is your jira-instance denying the creation of the ticket, while the form didn't indicate to your user they needed to add that.

About the error, it's hard to tell exactly what's the problem without more details - I would advise sharing some screenshots of your automation so we can help. 

On guessing grounds, it could be syntax error (using custom_field name on advanced value setting) - it could be invalid values on the Service Request Ticket, being copied to a field that doesn't accept that value type (eg: User picker to Date) - it could be that your destination issue type doesn't contain the necessary field on its view.

Happy to help debugging if you share more information.

Hope it helps!

Bests,

Marcos Defina.

Matthew Valley January 29, 2025

Hi Marcos, thanks for your reply.  

To troubleshoot my issue I've setup a clean and isolated test project.  I'll walk through setting up my system step-by-step and hopefully you'll be able to see where I've gone astray.

1. I'm starting with a new company-managed service project. 

2. In Settings:Request Management, I created a new form.  For this test, the form is minimal and only contains a field to select today's date

3. In Settings:Request Management:Request Types I created a new service request task.  I attach the form to this new request task.  

4. I create a simple automation:

When: Issue Created

Then: Clone Issues into Project B

where Project B is the same project used in my original post (the one that is blacked out for privacy reasons). 

With this system in place, I can access the form from the Portal, and create a ticket in my test project.  However, the automation to clone this ticket into Project B fails with the following message:

Failed to fetch fields for project/issue type -

14515/3

This is a new error code, but since the failure also occurs in cloning a service ticket with an attached form, I suspect I am simply setting things up improperly.  

Thanks, Matt

Marcos Defina
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 29, 2025

That's ok Matt,

It's quite common to just reuse the code you already wrote in other automations, that brought the initial error to your sandbox test too.

It's just the double underscore as highlighted in other comments.

I hope that helps.

Marcos Defina
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 29, 2025

PS: whenever you have troubles like these, feel free to share some screenshots.

We're all here to help, but any ill intended person won't have enough information to cause a threat to your organization. Just be mindful of not displaying hardcoded emails, names and addresses on your screenshot and you'll be good.

Matthew Valley January 30, 2025

Thanks Marcos, 

After cleaning up the typo in the JSON (thanks for catching that) I still got the same message: 

Screenshot 2025-01-30 at 09.24.23.png

I now see the same error in my minimal test project as well, I had previously been using an 'issue type' = 'same issue type', but now I have changed this to 'Task' to align behaviour between the test and development projects.  

I have also tried the following to debug this:

1. Add 'Re-fetch Issue Action' immediately following the issue creation in the automation chain, as suggested by @Bill Sheboy here.  This does not change anything.

2. SOLUTION: Modified the destination project to a clean Software project.  I'm not entirely clear what is the difference between this new project and the previous one.  I suspect the new project has not inherited a list of custom field from the Company managed configuration, and so it is not demanding to map this particular customfield during the cloning operation.  

@Marc - Devoteam asked if the field is available in both projects, and I think the answer is no.  My permissions don't allow me to inspect the custom field list for projects so this is beyond the limit of what I can easily debug, so while I can't verify this is the problem it seems like a likely cause.  

While cloning works for me now, when I try to copy a custom field (in the example below, 11845 is 'Due date'):

Screenshot 2025-01-30 at 11.51.04.png

I get the following error (note: I also get this error when I remove the custom JSON field, above):

Screenshot 2025-01-30 at 11.52.56.png

Does this mean that the destination (software) project is not configured to accept this custom field?  If so how do I go about this configuration?  If not, what should I alter in the service project?  

If either of you can point me to documentation that describes how to correctly propagate custom fields during cloning I'd really appreciate it.

Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 30, 2025

Hi @Matthew Valley 

On the custom field context there is probably an/or issue type restriction an/or project restriction.

Also the field must be on the screens used by the project.

Check this with your Jira admin if you don't have permissions as admin or in the other project

Like Marcos Defina likes this

Suggest an answer

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

Atlassian Community Events