Automation problem with parent creating subtask based on a condition

[Nic Ban]

I have created Automation for user story issue. When the parent issue has a comment with text in the body that contain a specific string, the Automation will create a subtask. 

The problems I have:

-The regex does not strip out the #sub when creating the subtask title.

-Sometimes it will only create one ticket even though there maybe 2 or 3 comments with the text #sub. 

-Or Iget one ticket created and then the second time I get this error 

Create issue

Error creating issue

The summary is invalid because it contains newline characters. (summary)" or it won;t create multiple based on For Each. 

[Bill Sheboy]

Hi @Nic Ban -- Welcome to the Atlassian Community!

The replace() function works with plain text replacement, and not a regular expression.  Please try using replaceAll() instead: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#replace-String-target--String-replacement-  Or better still, use a match() as described below.

Next, you are trying to use an Advanced Branch, and your smart value expression will need to return a list if you want multiple subtasks.  I recommend trying a split("\n") before a match() function instead of replacement to isolate the data you want.  The match() function returns the first (and only one) match, and so the split helps to iterate first.

Finally, the documentation describes the regular expression / matching used in automation rules is based upon the Java Pattern class...but it does not indicate what actually is / is not supported.  Several community posts have described behavior that does not match the spec.  I recommend using the simplest expression that can possibly work, building up slowly until you get the result needed.  And, try writing your incremental progress to the audit log to confirm it works as you expect...especially for edge cases.

Please try those changes and see how they help.

Kind regards,
Bill

[Nic Ban]

Thanks Bill. I did rewrite the regex for my variable to this 
{{issue.comments.last.body.split("\n").match("#sub(.*?)")}}

Seems to have broken the automation.

I got this error 

Then I tried this code to account for newline characters
{{issue.comments.last.body.replaceAll("#sub(.*?)(\n|$)", "$1\n")}}


And this is the error I have been getting with past code.

 I only added the "#sub some test after for sub task title" on the 2nd and 3rd comments, not the 1st.

[Bill Sheboy]

Would you please post an example of the comment you are trying to parse?

And, if you write both the un-parsed comment and the smart value expression driving the branch to the audit log before the branch, how do those compare to what you expected to see in the results?

[Nic Ban]

Hi Bill,

Does this help?

So if a comment in the parent issue does not contain the text/string "#sub" , then the automation does not run. 

If a comment in the parent issue contains the text/string "#sub" , this triggers the automation to create a subtask and use the string after the text "#sub" use any text after #sub to generate the title until either a period or a newline.
All other text after the #sub line will be the description. I have had success with before trying to strip out the "#sub" from the newly created sub title

[Bill Sheboy]

Thanks for clarifying your scenario. 

The match function is limited to finding the first thing, and...The advanced branch input needs to be a list, not an array.  The details of your scenario seem to be:

• when an issue is commented upon only (and not for an issue create)
• for 0-to-many expressions found starting with #sub in the comment
• grab the text immediately after the #sub as the Summary for a new subtask, up to either a period or newline to end the Summary
• grab the text remaining for the new subtask Description, up to either the end of the comment or the next #sub

I recommend parsing this way to simplify a bit for the advanced branch:

• replace all newlines with a period  (Unfortunately, this will remove any newlines intended for your Description field.  And...you may want some clean-up to remove any extra periods in the resulting Description.)
• remove all text before any #sub with a match()
• split on #sub to feed the advanced branch input
• inside of the branch...
  • check if the variable is non-empty
  • grab the text before the first period as the Summary
  • grab the text after the first period as the Description

And so your advanced branch input could be:

{{issue.comments.last.body.replace("\n", ".").match("(#sub.*)").split("#sub")}}

[Nic Ban]

Hi Bill, I modified my regex to have an ending #end so this helped resolve any issues.

One last question, how can I get a comment that was edited. So if someone adds a comment and later decides it needs to be a subtask. So they edit their comment and add the trigger #sub, what is the smart value for this?

Currently, the edited comment automation is not working and I believe it is because of the smart value/ condition  is not correct. 

Here in the image is what I have tried. I have also tried {{issue.comments.updated.max}}

[Bill Sheboy]

That is a trickier scenario...please review my long-winded thoughts to consider how to proceed :^)

Your current rule uses the trigger where the primary activity was commenting....which is for new comments only.  There is a separate trigger for comment updated, and so that could be used for changes using another rule.

When you start dealing with updates, you have a few things to consider:

• How do I detect if a subtask's summary changed, versus a new one was added?
• How do I handle the Description changing for an already existing subtask?
• Do I add new subtasks if they did not exist...assuming only #sub was added?
• Do I remove any subtasks if #sub is removed?
• And the brain-bender: If I add a #sub, the content was probably already added to the Description of the subtask before it in the list.  Opposite problem if a #sub is removed.  What do we do now?

This complexity is due to the bundling of things in the comment.  Only you and your team can decide if the likelihood of a comment being edited is worth handling the added complexity for this.