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:
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.
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}}"
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for this suggestion!
The clone operation already has some JSON code, here it is with the addition of your code above:
I've placed your code snippet where I gather it belongs based on this article.
However, my error message now reads:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is the field available on the other project?
And is the rule scoped for both projects?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Marcos,
After cleaning up the typo in the JSON (thanks for catching that) I still got the same message:
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'):
I get the following error (note: I also get this error when I remove the custom JSON field, above):
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.