Simmo Atlassian Team

Since you guys asked, here's a sneaky look at what may, or may not be, the final UI.

Heya folks! This was my innovation week project and it is coming to Automation rules near you soon. The docs unfortunately got published a little early. We're dogfooding it ourselves at the moment to make sure its solid. I've already found one little issue with it. Since you asked, I'll get a screenshot shortly.

Hi @Bill Sheboy, Great question. I wrote an automation rule that recreated the popular issues into the AUTO project and then one of our PMs did some tidying up. So, you are right in that the comments haven't been carried across. If there are any in particular, I can go and pull them out if they're needed. However, we felt…

Ouch, thats a bit nasty. @Bill Sheboy was on the right path with this one. I suggest that you use an advanced condition here: Do this after the clone. If the clone is successful then you'll have a created issue smart value. Check if it does not equal empty and then you'll only continue the rule if it was successful. Note:…

Hi @Patrick Lowry, I'm afraid that at the moment this is a Cloud only feature. 

Hi @Yatish Madhav, I think you've already found the answer. It looks like you have to set this particular field by its ID, hence the Can not deserialize instance of java.lang.Long. It appears to be expecting a number when you set it. I'm not sure that you can get around this. Unfortunately, you tried my only other…

Ah yeah, I can see that being a little confusing. As @Bill Sheboy said, the fieldChange is in relation to the trigger.

Pretty much what @Bill Sheboy said :) Though, if the assignee was changed as part of the transition, it might be available in the changelog.

Hi @Geoff Worling, What are you expecting the fieldChange.fromString to be? 

Hi @Geoff Worling, is the assignee getting changed as part of the transition? If you could show a screenshot of your rule it would be really helpful. 

It might also be a false positive. The automation rule is going to be triggered for every created issue in that scope and it won't always be your epic, so you will see that message from time to time.

Could you include a screenshot of the rule configuration so far?

That's right, the JQL is intended to help balance the load not filter out

Hi @andrew_pass Could you provide a screenshot of the rule and what you have so far? Cheers, Simeon. 

It sounds like you might need to use Clone issue perhaps?

Hi @Nicklas Madsen, Are you getting any errors in the audit log or is it just not working? 

I second this. You won't he able to do this in smart values so in the JQL filter it down to just breached ones and then you can use the count of issues returned by lookup issues.

Hi @Yatish Madhav, I suspect that the field is storing the data in an interesting/non standard manner. Could you create a test issue, set the field and then provide an export of the issue in JSON format? Easiest way to do that is to use the URL format: https://XXXX.atlassian.net/rest/api/2/issue/BIO-445?expand=names Where…

Hi @Mélanie Liguet, If this doesn't work, if you can provide an example of the output (maybe sanitise anything sensitive) then we can help figure out what the smart value should be. Cheers, Simeon. 

Hi @Christel Gray, You should be able to do this with some branching and the related issues condition: This example needs some extra checks that @Trudy P Claspill did with checking the components and not sub task, etc but this should show you how to do it. We branch onto the epic and then use the related issues condition…

Hi @Kaushik Battu, Your result is [ ], which is an empty list and indicates that there were no results.

Hi @Stefan Peev, Have you tried just setting the reporter to their email address and seeing if that works? 

Hi @Mario Benedí Plana You can add default values to your smart values to catch a missing value and stop the expressions breaking. Just add |0 to it. For example: {{issue.customfield_10181|0}} Will default to 0 if there is no value. Hopefully that helps. Cheers, Simeon.

Hi @Geetha, Pretty much everything that @Bill Sheboy said. To be able to work across projects you need to be a site admin, for pretty much the reasons that Bill explained. Cheers, Simeon. 

@Ben, the suggestion from @Joseph Chung Yin is the only way to solve this. There isn't an API for Automation to be able to call that will achieve this. This is why you're getting the field error message. 

Hi @Anthony Soller, Probably the best bet for this one is to setup a test rule using one of these sub tasks, see https://support.atlassian.com/cloud-automation/docs/test-a-jira-automation-rule-using-the-manual-trigger/ and https://support.atlassian.com/cloud-automation/docs/debug-an-automation-rule/ Then you can have a…

Hi @Patricia Francezi_iDev_, Approvals is a list type. If you always want to get the last approval then you should refer to it by: {{triggerIssue.Approvals.last}} This will give you the last approval in the list. Cheers, Simeon.

@Bill Sheboy not in this case I'm afraid. It should be available or the rule would have errored. Would probably have to work backwards and start by adding a log component for {{issue}} and see what that gives, then go from there.

If there is an easy way to identify this you could maybe use an issue created trigger and add the label that way?

Hey @Bill Sheboy, I like it, thats some fancy thinking! I think so. {{issue}} should still work I believe so you can get the issue key that way!