Can't use smart value to update Epic Link in Jira Automation?
Asked by Jira Testing:

Hi everybody,

I'm desperately trying to update the Epic Link field using a regex that returns a smart value. Only, when I run the automation, I get an error of (gh.epic.error.not.found)

The proposed workflow:

1. An email is generated from a form.

2. An email is sent to the JIRA mail handler on the our JIRA.

3. When that email gets turned into a ticket, the description field is populated with all these values from the email body.

4. One of those lines in the email will be "EPIC:" and populated from a list of already existing epics.

5. If "EPIC:" exists on the email, the JIRA automation uses this current regex expression to pull the value from that field. (I have it manually triggered right now so I can test without having to create a ticket every time)

{{issue.description.match("(?:\[EPIC:\]+(\[a-zA-Z\\s\\W\\d\]{2,14}))")}}

6. For some reason, I can't change the Epic Link field without running into the (gh.epic.error.not.found) error.

If I'm able to get this to work, I'll be able link incoming ticket to the right epic dynamically.

Anything I'm doing wrong?

![image (10).png](/t5/image/serverpage/image-id/140691i4D9395C4E7DA7647/image-size/large?v=v2&px=999 "image (10).png")


Answers:
author: Bill Sheboy
body: Hi [@Jira Testing](/t5/user/viewprofilepage/user-id/4368955) -- Welcome to the Atlassian Community!

A couple of things to help diagnosis this issue:

* Use the parsed description (epic key) to create a variable
* Log the variable to the audit log

Then check to see what you are getting, and confirm both that your RegEx works as you expect and that there are no extraneous characters.

And, I wonder if you can use the created variable to set the epic link but cannot use the more complex expression (which parses the description) for some reason.

<br />

Best regards,

Bill

comments: author: Jira Testing
body: Unfortunately, I'm using JIRA Server and we don't have that automation yet.   

I've tried a work around; setting a custom field with the value returned from the regex and then trying a seperate automation to pull the value from that custom field into the Epic Link. Although, I get the same error of (gh.epic.error.not.found)


author: Bill Sheboy
body: If you log the parsed description directly to the audit log, do you see what you expect?

And, if you are writing the key to a custom field, and then using that field to set the epic link, you will need a Re-Fetch action after the custom field is set. Otherwise the rule will use the value of the custom field from the time when it was first loaded, not after the edit.


author: Jira Testing
body: I logged the parsed description directly to the audit and got exactly what I expected, the key for the epic.

I wrote to the custom field manually and triggered the automation after that custom field had already been set.


author: Bill Sheboy
body: Thanks for that information.

Would you please post an image of the edit action in your rule showing where you are trying to set the epic link?

What is the issue type which you are trying to set the epic link for?

And, have you confirmed that the Epic exists for the key you are trying to set? That specific error can show when the epic does not exist yet.


author: Jira Testing
body: I solved it by messing with the regex. Apparently, even though the console won't log the extra whitespace at the end, the Epic Link field was pulling it in alongside any new line.  

I'm using the same kind of regex to parse for Story Point fields but I'm having trouble converting the string value into an integer. Is there anyway I can manipulate a smart value to return as an integer?

Something like:

{issue.description.match("(?:\[SP\]+\[:\](\[0-9\]{0,2}))")}}.JsonInteger?


author: Bill Sheboy
body: Have you tried .asNumber That works for Cloud, although I do not see it listed in the Server documentation.


author: Jira Testing
body: Just tried, but I wasn't even able to get it to even log anything.


author: Jira Testing
body: Just got it to work by tweaking a custom field. This works great for me, thanks!


Tags: cloud