Forums

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

Automation fails to extract a URL from the description when creating or editing. User edits work.

chris_b
Contributor
May 30, 2023

Forgive the unhelpful summary/question. There are a lot of aspects to this, and I've tried as many tricks as I can think of.

--------


I have six rules in place that extract specific data from the description of a ticket (the tickets are created by an external app), and then place the info (urls) into custom fields for the purpose.  We cannot control where the app puts the data, so it's all just part of the description and Jira automation does the processing.

One of the rules (only one, which is strange because they're clones of each other) fails unless a user edits the ticket, in which case the rule works correctly.  If automation triggers the same rule or the "Create" version of the rule, it will fail to extract the data and will just empty the field (fills with whitespace I suppose)


The rules work like this:

CREATE rule 
Trigger: Issue Create
(Conditions based on Issuetype and a required label)
Actions:
-create a variable using {{issue.description.substringBetween("Url:*","*UniqueIdentifyingText:")}}
-create a new variable with junk removed from the first variable (formatting causes issues, so I'm stripping the formatting using a series of {{MyVariable.remove("*")}} actions.
- (logs the variables to the audit log at every step, so I can make sure the processing works)
- ...repeat as needed

Finally, take the final variable content and add it to my short-text field.

EDIT rule (this is a clone of the other rule with the trigger changed.  This is a required rule because our external app will sometimes update the description, and we need to know the new URL)

Trigger: Edit Description field (for all issue operations except create)
(Conditions based on Issuetype and a required label)
Actions:
-create a variable using {{issue.description.substringBetween("Url:*","*Text:")}}
-create a new variable with junk removed from the first variable (formatting causes issues, so I'm stripping the formatting)
- (logs the variables to the audit log at every step, so I can make sure the processing works)

Finally, take the final variable content and add it to my short-text field.


There are 3 sets of these rules, one set for each of the URLs the external app provides us in the description.   TWO of the three rules work correctly in every case, but one does not (the github one)

So, when the external app creates a new ticket, 2 of the 3 "URL" fields are extracted correctly (they're short text fields, not the actual URL custom field)
The last one will always fail.  If I then manually edit the description field in any way, the EDIT version of the rule will successfully run and I get my last URL.

If I set up that Edit rule to run when triggered by another rule, it will claim success but will empty the final URL field.  If I set up a rule to to manually edit the description, the rule will still fail.

TLDR, there is a meaningful difference between automation editing the Description (in any way), and a user editing the description manually.  


Does anyone have any suggestions?  The information inside the rule is sensitive, so I can't post the actual audit messages here, but if needed I can obscure that info and post them.  Just wanted to see if anyone has a "oh  you forgot _____" suggestion before I do that.  

 





1 answer

0 votes
Trudy Claspill
Community Champion
May 30, 2023

Hello @chris_b 

Welcome to the Atlassian community.

Just for clarity, in the logging of data in the rule that doesn't work, are the logs revealing that the text extraction steps are working successfully? 

Immediately before setting the field with the extracted text, do you have a log action to log the value of smart value you are using in the Edit action?

Have you double checked that the variable you are using in the Edit action is the right variable used to extract the text in that rule?

Check for a typo in the smart value you are using in the Edit action. If there is a typo, the rule will still show success over all while the field being set ends up with no value.

chris_b
Contributor
May 30, 2023

Hi Trudy!

The rules are clones, and the one that fails (when automation triggers is) works when the user manually edits the description field. 

When the rule successfully runs (when manually triggered by a human), each variable prints exactly as expected at each step of the way, but when it fails (when automation triggers it), each variable is blank at each step.

I've quadruple-checked my variable names, they're all correct.

So, in my audit log the failed (but reports as success) my output is something like ~

"       " <- Extracted URL
"       " <- URL with * removed

(and so on, no quotes used in the actual logging though - that's just so you can read this)

Trudy Claspill
Community Champion
May 30, 2023

Hm, this is puzzling.

So there are two rules for getting the github text, right?

One is triggered by issue creation and one is triggered by issue editing, right?

You said "the rule" fails when triggered by automation, but succeed when triggered by a person. Do you mean both the Issue Created and Issue Edited rules fail when triggered by automation?

Is there any difference in the github text when it is entered by a human vs. what is entered by automated processes?

Is there anything distinctive about the text for github as compared to the text for the other URLs you are extracting? Does the github text contain any non-alphanumeric characters that aren't present in the other URLs?

Do all the Issue Created (or Issue Edited) rules get triggered on the same issues? What is the timing of the triggering of the rules? Which one gets triggered first, second and last? Are they always triggering in the same order? I'm wondering if there might be a timing issue.

Do you happen to have a Re-fetch action in your rules prior to starting the text extraction steps?

chris_b
Contributor
May 30, 2023

These are the questions I asked myself!  

You're correct, there is a "create" version of the rule, and an edit version of the rule.  The trigger is the only difference, and WHO triggers it matters (that's the weird part).

There is nothing special about the github url, it's just a url (and when a human triggers the rule it works, so the formatting isn't really a problem).  The characters are http://github.com/thing/otherthing .  One or two have a hyphen, but they work fine when humans trigger the rule.

I've played with the triggers, and even went to far as to make new rules that will just add a hash # to the end of the description to simulate a human editing the description, and that actually causes the "success" where it just clears the field.

I used re-fetches in between each step, at the start, and in my terrible rule where I had a hash, just to see if the jira version of a "wait" would allow the URL to render it's alias, but that didn't seem to matter.  I even went so far as to string 4 refetches together, just to stress the system a bit.

All the rules trigger on the same issues.  We created a specific issue type (security task), and add a label just so we don't accidently mess with tickets outside the scope of this work.  That also allows me to control the workflow for the issue type (and screens, etc).

This process is new to us, but we've run the rules ~100 times and the outcomes are always:
4/6 rules are awesome and do what they should.
2/6 rules fails if the automation triggers it
1/6 rules (basically the edit version of the 2/6) works when humans trigger it through a description change
The last version, a human CREATING the ticket hasn't been checked because it's not how the system would work (but I'm thinking I might have to just try that anyway....)


(really weird, right?  It's ONLY the "who" triggers the rule that seems to matter)


chris_b
Contributor
May 30, 2023

(I've also played with the rule timing - no difference.  The checkmark for "allow this rule to trigger another change..." didn't help, it actually caused the rule to loop and clear the field again)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events