You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.
View groupJoin the community to find out what other Atlassian users are discussing, debating and creating.
Update: There are two issues. One is being unable to write a JSON object using the set entity property. The other is that you cannot retrieve the entity property as a JSON object, it is returned as a string see AUT-1696.
We are attempting to copy an entity property from a parent issue to a subtask. Everything is working as expected; however, when we use the Set issue property it writes the values as a string and adds quotation marks around the json we are adding, which makes the JSON invalid.
Is this a bug or is there some work around?
The automation rule we have created is:
The result is this
Simon - yes, I've been telling Atlassian that A4J's JSON handling is broken.
I assume you didn't find a solution (?)
Did you email support? We can't vote on issues on the old codebarrel site, so at least this adds context and pressure on them.
Hey all - has anybody tried this lately?
As recently as last week, I was able to "extract" values out of a project property that looked like this:
{
"engineering-approver-primary": "someaccountid",
"engineering-approver-secondary": "someotheracccountid",
"build-approver-primary": "thisaccountid",
"build-approver-secondary": "thataccountid"
}
My trick was using a web request to get the data out, and into {{webhookResponse.body}}, where I was then able to use {{webhookResponse.body.value.engineering-approver-primary}} to update a User field.
I had to use a web request because there is no way to currently reference (evaluate/nest) a smart value within a smart value.
Like, I ideally I'd be able to simple update a field by doing:
{{project.property.{{issue.component.value}}.value.engineering-approver-primary}}
But that's not a valid Smart Value.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oh, but to Simon's original message, it seems like I *was* able to write a valid JSON object using the set entity property. At least it was valid enough for it to be properly parsed as a {{webhookResponse.body}}.
I set the Property value above using this code:
{
"engineering-approver-primary": "{{issue.Engineering Approver Primary.accountId}}",
"engineering-approver-secondary": "{{issue.Engineering Approver Secondary.accountId}}",
"build-approver-primary": "{{issue.Build Approver Primary.accountId}}",
"build-approver-secondary": "{{issue.Build Approver Secondary.accountId}}"
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So I'm guessing for you, @Simon Herd, it's the {{issue.parent.properties."proforma.forms"}} that's introducing the extraneous quotation marks.
I think Automation could really use the inverse (converse?) of the asJsonString function.
> stringAsJson or something would attempt to parse a string into a JSON object.
Or they could just recognize a JSON object and return it appropriately. :-P
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We often have questions from folks using Jira Service Management about the benefits to using Premium. Check out this video to learn how you can unlock even more value in our Premium plan. &nb...
Connect with like-minded Atlassian users at free events near you!
Find an eventConnect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.
Host an eventYou're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.