So close! Add multiple accountID Strings to User Picker(Multi)

[Evan Nixon]

Hello! 

I have had an unbelievable struggle getting this automation to do it's thing, and I'm very close to the finish line, hopefully someone can point out the silly mistake I've made and get this across the finish line. 

Here's the layout as is.

The objective to give people the ability to flag a particular user in a comment by putting an exclamation mark after their mention. The automation should then pick up that user's ID string and add it to a custom multi-user picker. 

Using a conditional check of {{comment.body}} for \[~accountid:.+\].*! works perfectly, and the below smart value (and string it outputs) seems like the right combination to put into the multi-user picker, but no matter what it gives me the below error in the log. 

The second string in the log is a .asJsonArray render from the {{Test}} custom smart value, which has the same smart value is as in the JSON additional field - just with ".asJsonArray" at the end. I've attempted to have the two strings with no space between the comma and second string, only the comma, only a space, asJsonString, asJsonArray - no luck with any of them. 

So after all this : what on earth is the delimiter or format needed for multiple id strings for them to to be accepted by a multi-user picker box?

[Darryl Lee · Accepted solution]

Hi @Evan Nixon -

Based on this documentation for overwriting a Multi-user picker custom field:

"customfield_11458" : [ { "id":"2s1863211f0z284c45269423" }, { "id":"332212e13z52142111269423" }]

Maybe for an ADD you would also use just id instead of accountId?

[Darryl Lee]

I guess you could call this the "documentation" for this:

Fields specified by an "ID" type use the attribute "id". For system user fields (only) we allow "accountid" as a synonym. For custom user fields you need to use "id", like:

{
    "fields": {
        "customfield_10055": [
            {
                "id": "0f0000fff0ffff0f0000f00f"
            }
        ]
    }
} 

From JRACLOUD-72000 

[Darryl Lee]

I have this excellent resource bookmarked, but completely forgot about it until researching the above answer:

JSON input for fields 

Although @Radhika Vijji _Innovalog_ and @David Fischer suggest the correct format for User picker (Multi-users) is:

[{"accountId":"accountId:557058:3a41d4ee-3331-4363-8cdf-f90a2da92f7e"}],
[{"accountId":"accountId:557058:3a41d4ee-3331-4363-8cdf-f90a2da92f7e"},{"accountId":"accountId:557124:3a41d4ee-3331-4363-8cdf-f90a2da92t4e"}]

So, now I'm not so sure about the "id" suggestion.

I suppose you could try them both.

[Bill Sheboy]

Hi @Evan Nixon 

Yes, and...to what Darryl notes: If you expect there could be multiple mentions in the comment, I do not believe there is a built-in way to parse those values into JSON for the edit of a multi-value picker field. 

A work-around is to get your id list into a created variable, and then use list iteration and text functions to dynamically build the JSON into another variable.  Finally use that last variable in the update.

Kind regards,
Bill

[Evan Nixon]

Thanks @Bill Sheboy and @Darryl Lee for your replies, greatly appreciated. 

I have managed to get the string output exactly as recommended in the link Darryl supplied in his last comment (thank you for that by the way, that page blows Atlassian's documentation out of the water - fantastic resource. 

This is the smart value I'm using :

{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").replace("[~accountid","accountId").remove("] \!").asJsonObject("accountId").asJsonArray.replaceAll("\\s","")}}

Which using the example mentions/comment in my original post outputs :

[{"accountId":"accountId:610a6c430b454a00681be664"},{"accountId":"accountId:5d53f3cbc6b9320d9ea5bdc2"}]

This output string matches exactly what is mentioned in the link Darryl provided, and getting it to output like that was unbelievably difficult - the documentation for ".asJsonObjectArray()" is....not great. 

Now for the final frustration which has me completely lost - the automation finally actually succeeds, but the field does not actually update. 

This JSON shows success in the log, but no users are actually added to the custom multi user picker field. I have also tried every other JSON format I can think of (you should see my Notepad++ scratch file for this) and none of them have shown success in the automation log other than this.

{
"fields":{
"customfield_10632": [
{
"set": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").replace("[~accountid","accountId").remove("] \!").asJsonObject("accountId").asJsonArray.replaceAll("\\s","")}}
}
]
}
}

Before you suggest it - yes, I have tried using the "add" operator instead of "set", it also succeeds in the log, but fails to actually do anything. 

I am beyond lost on what to even try next as a troubleshooting step.

[Evan Nixon]

Just to make sure I'm showing my work here, attached are some screenshots of the automation - as well as a .JSON export of the rule itself on Google Drive. Apologies for the odd aspect ratio of the screenshots (or if the JSON is formatted incorrectly after I removed the rest of the rules from the global export, I'm on mobile at the moment.)

[Darryl Lee]

@Evan Nixon did you try using just id, as in:

[{"id":"610a6c430b454a00681be664"},{"id":"5d53f3cbc6b9320d9ea5bdc2"}]

Because that's what an Atlassian developer, @Ben Kelley suggested in JRACLOUD-72000.

[Evan Nixon]

Hi Darryl,

Here's what I've tried this morning.  The smart value below the breaks is what's in the {{Test}} smart value, and the output of the smart value is just below that. First up is your suggested format :

[{"id":"610a6c430b454a00681be664"},{"id":"5d53f3cbc6b9320d9ea5bdc2"}]

###########JUST "ID" SETTINGS###########


{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
[{"id":"610a6c430b454a00681be664"},{"id":"5d53f3cbc6b9320d9ea5bdc2"}]


Succeeds, no actual update to field. 
{
"fields":{
"customfield_10632": [
{
"set": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Succeeds, no actual update to field. 
{
"fields":{
"customfield_10632": [
{
"add": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Fails, "Error while parsing additional fields. Not valid JSON."
{
"fields":{
"customfield_10632": [
{
{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Succeeds, no actual update to field. 
{
"update": {
"customfield_10632" : [
{
"add": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Succeeds, no actual update to field. 
{
"update": {
"customfield_10632" : [
{
"set": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}
]
}
}


Fails, "Error while parsing additional fields. Not valid JSON."
"customfield_10632" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}


Fails, "No fields or field values to edit for issues (could be due to some field values not existing in a given project):
IA-176"
{
"customfield_10632" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","")}}
}

 


#####################################PLAIN STRING IN JSON OBJECT ARRAY#####################################

{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}
[{"610a6c430b454a00681be664"},{"5d53f3cbc6b9320d9ea5bdc2"}]

Fails, "Error while parsing additional fields. Not valid JSON."
Think this one's format was weird, used the wrong template from a much earlier version
{
"update": {
"customfield_10632" : [
{
"add": {
"accountId" : "{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}"
}
}
]
}
}


Fails, "Error while parsing additional fields. Not valid JSON."
{
"fields":{
"customfield_10632": [
{
"add": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}
}
]
}
}


Same as last attempt, just with quotes added around smart value. 
Fails, "Error while parsing additional fields. Not valid JSON."
{
"fields":{
"customfield_10632": [
{
"add":"{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}"
}
]
}
}


Fails, "Error while parsing additional fields. Not valid JSON."
I think that when I used the {{Test}} value to validate the output in this variant it accepted single \ to make the " at the end of the expression literal, but because it's being parsed through JSON first then being converted to a smart value it may need it twice.
{
"update": {
"customfield_10632" : [
{
"add": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}
}
]
}
}

Fails :
Edit issue
Error while rendering additional fields.
Failed to get value for issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\"id\\":")

Okay what the frick, I'm just going to put the {{Test}} value in. 
{
"update": {
"customfield_10632" : [
{
"add": {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\"id\\":")}}
}
]
}
}

Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
"add": {{Test}}
}
]
}
}

######SOME OF THE SAME AS ABOVE BUT USING ADD + ID INSTEAD OF ACCOUNTID######

Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : "{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}"
}
}
]
}
}

Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}
}
}
]
}
}

Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\"id\":")}}
}
}
]
}
}

Same as above with double backslash
Fails,
Edit issue
Error while rendering additional fields.
Failed to get value for issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\"id\\":")
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\"id\\":")}}
}
}
]
}
}

Same as above with triple backslash
THIS IS NEW!!!!
Fails,
Edit issue
Error editing issues
IA-176 (The customfield_10632 (id) must be a string (customfield_10632))
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\\"id\\\":")}}
}
}
]
}
}

Same as above, with quotes added around smart value
Fails, "Error while parsing additional fields. Not valid JSON."
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : "{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\\"id\\\":")}}"
}
}
]
}
}

Same as above, with spaces added before quotes added around smart value
Error while parsing additional fields. Not valid JSON.
{
"update": {
"customfield_10632" : [
{
"add": {
"id" : " {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\\"id\\\":")}} "
}
}
]
}
}

Same as above but removed quotes and switched to "accountId" instead of "id"
Fails, IA-176 (The customfield_10632 (accountId) must be a string (customfield_10632))
{
"update": {
"customfield_10632" : [
{
"add": {
"accountId" : {{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id").asJsonArray.replaceAll("\\s","").remove("\\\"id\\\":")}}
}
}
]
}
}

The last thing I've been trying is what I initially had success with for a single user which was just a plain string.

"add": { "accountId" : {{SmartValueThatRenders : 610a6c430b454a00681be664}} }

As in the last example in my large codeblock above I've gotten a totally new and fun error "(The customfield_10632 (accountId) must be a string (customfield_10632))".

Figuring this out is making me regret my entire existence. Good god, what a nightmare. 

[Bill Sheboy]

Hi!

As a reminder: "fields" is a shortcut for using "update" and "set".

https://support.atlassian.com/jira-software-cloud/docs/advanced-field-editing-json/#Advancedfieldediting-JSON--What-sthedifferencebetweenupdateandfields

As you want to perform an "add" please try switching "fields" to "update".

Next, I have definitely run into issues where the field objects could not be used directly in the JSON edit expressions.  This is why I suggested using a created variable to perform that regular expression parsing, saving the result as text.  And then use list/text functions to build your "add" expression before putting it in the update.  As you progress, write the intermediate values to the audit log to confirm you are getting what you expect.

[Darryl Lee]

Hey hey, also, for sanity, I would suggest creating a Test rule where you hardcode the JSON with the right IDs:

You could try both "id" and "accountId" and then use a Manual Trigger to see if it works at all.

[Darryl Lee]

The beauty of the Manual Trigger is you can keep trying different fields/formats/etc., saving, and then use the Manual Trigger on an issue open in a different window until you (hopefully) find something that works.

[Darryl Lee]

I haven't spent too much time on this, but this ugliness works. Having to create multiple add statements sucks though:

{
   "update": {
      "customfield_10102" : [
         { "add": {"id" : "5ffcb54bf7ea2a0107eab167"} },
         { "add": {"id" : "60025fba332c3a01075d484c"} }
      ]
   }
}

[Darryl Lee]

As I'm re-reading the documentation on Automation for editing for Labels fields it looks like they specifically make a distinction between setting the field (which accepts an array):

"labels" : ["examplelabelnumber1", "examplelabelnumber2"]

And for adding a label, it shows only a single value:

{
    "update": {
        "labels": [
            {
                "add": "my-new-label"
            }
        ]
    }
}

So then, if you're wanting to add (without overwriting existing users in the field), you'll have to generate multiple add statements.

Otherwise, let's see... ok, yes, this worked for me just now:

{
   "fields": {
      "customfield_10102" : [
         {"id" : "5ffcb54bf7ea2a0107eab167"},
         {"id" : "60025fba332c3a01075d484c"} 
      ]
   }
}

Thanks @Bill Sheboy for reminding us, as the docs say, "fields is a shortcut for calling update with the set operation."

[Evan Nixon]

@Darryl Lee  and @Bill Sheboy, you are absolute scholars and gentlemen - the main issue here is finally sorted. The last bit I needed to figure out was how to merge the solution Darryl provided with the advice from Bill, which individually worked for multiple user mentions or single user mentions, both with and without other users already present in the field. I can't tell you much I appreciate all your help so far, but suffice it to say it's a lot.

There is one last bit before this is completely done that I'd love any advice on at the bottom of this - but at least the huge question of "how the hell do I add multiple users to a custom User Picker" is sorted thanks to both of your advice. An ELSE IF gate works nicely here. 

Rule is triggered on

     All comments

 


Advanced compare condition

     First value

          {{comment.body}}

     Condition

          contains regular expression

     Regular expression

          \[~accountid:.+\].*!

 


Add Log Value

          REGEX TRUE

 


###IF###

Waiting on Reply is empty

     Add log value

          IS EMPTY

 


     Edit issue fields advanced

          { "fields": { "customfield_10632" : [{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id")}} ] } }

 


###ELSE###

Waiting on Reply is empty

     Add log value

          IS NOT EMPTY

 


     Create variable

          Variable name

               Users

          Smart value

               {{issue.customfield_10632.accountId.asJsonObject("id")}},{{issue.comments.last.body.match("(\[~accountid:.+\]*!)").remove("[~accountid:").remove("] \!").asJsonObject("id")}}

 


     Edit issue fields advanced

          { "fields": { "customfield_10632" : [ {{Users}} ] } }

 

###FINAL TESTS###

##IF##
Waiting on Reply is EMPTY

          Single "@Mention !"
                    SUCCESS
          Multiple "@Mention !"
                    SUCCESS

##IF ELSE##
Waiting on Reply is NOT EMPTY

One User in Field
          Single "@Mention !"
                    SUCCESS
          Multiple "@Mention !"
                    SUCCESS

Multiple Users in Field
          Single "@Mention !"
                    SUCCESS
          Multiple "@Mention !"
                    SUCCESS

Now here is the final piece to make this automation complete : Removing a user who is present in "Waiting on Reply" (AKA "customfield_10632") from that field once they have commented on the issue.

I've added an "IF" gate that checks if {{issue.customfield_10632.accountId}} contains {{initiator.accountid}} (or {{issue.comments.last.updateAuthor.accountId}} which outputs the same thing). This works fine for targeting the automation, but getting the Commenter removed from the Waiting on Reply field is proving much more slippery.

My first thought for how to accomplish this was simply :

{ "fields": { "customfield_10632": [ { "remove": "{{initiator.accountid}}" } ] } }

Which does remove the initiator/commenter from the field.....as well as everyone else, which is definitely not the desired behaviour.

I then attempted to accomplish this with the below smart values and functions to manipulate them.

//THIS VALUE NEEDS TO BE REMOVED
{{initiator.accountId}}
          Output : 610a6c430b454a00681be664

//FROM THIS STRING
{{issue.customfield_10632.accountId}}
          Output : 610a6c430b454a00681be664, 5d53f3cbc6b9320d9ea5bdc2, 5cf112d31552030f1e3a5905

//WHICH CAN THEN BE FORMATTED
{{UpdatedSmartValue.asJsonObject("id")}}
          Output : { "id": "5d53f3cbc6b9320d9ea5bdc2" }, { "id": "5cf112d31552030f1e3a5905" }

//AND PUT BACK INTO 
Edit issue fields advanced
          { "fields": { "customfield_10632" : [ {{UpdatedSmartValue.asJsonObject("id")}} ] } }

I thought this would all be dead easy using a simple .remove("") function :

{{issue.customfield_10632.accountId.remove("({{initiator.accountId}})")}}

Unfortunately, this fails. I think it fails due to using nested smart values, which is not something you can at the moment (but is a requested feature here). 
@Bill Sheboy  has suggested that I do this with conditional list filtering - however after digging through the list and conditional logic documentation I'm not finding myself much closer to the answer.

Is there some way to remove {{initiator.accountid}} from {{issue.customfield_10632.accountId}} that I'm totally missing?

[Evan Nixon]

Solved it, thanks to yet another nugget of wisdom provided by @Bill Sheboy in this thread.

{{issue.customfield_10632.accountId.remove(initiator.accountId).asJsonObject("id")}}

OUTPUTS

{ "id": "557058:f58131cb-b67d-43c7-b30d-6b58d40bd077" }, { "id": "" }, { "id": "5d53f3cbc6b9320d9ea5bdc2" }

Despite the stray "{ "id": "" }," bit of the string, it still works exactly as intended. Booyah.

Here's the final automation flow with a branch for removing commenters from the field:

Finally. It's done. 

In Review

The goal of this automation (which has finally been reached) is : 

A user can add an "!" after a mention of another user in a comment. The automation will put the flagged mentions into the "Waiting on Reply" field. On our main dashboard users have a "Waiting on My Reply" widget, which populates via JQL Filter 

"Waiting on Reply[User Picker (multiple users)]" = currentUser()

This shows all the tasks where their name is present in the Waiting on Reply field so that they can see what tasks need their attention.

If a user currently in the Waiting on Reply field of a task then leaves a comment on that task, they are automatically removed from the field, and one less task is shown under their "Waiting on My Reply" widget on their dashboard. 

Again - immensely grateful to @Bill Sheboy and @Darryl Lee for your help getting to this point. 

[Bill Sheboy]

Evan, I am glad to learn you got this one to work.

Looking over your final rule, it appears you are editing the same trigger-issue multiple times throughout.  To avoid "walking over" prior changes, carefully consider if you need to add any re-fetch actions after edits.  Remember the in-memory copy during rule execution is not updated by edits: it still contains the values at trigger time...unless you add a re-fetch to reload it.

Kind regards,
Bill

[Evan Nixon]

Hi Bill,

I don't think the rule is actually overwriting itself at any point because of the IF/IF ELSE gates. 

The first branch only runs if the commenter is present in the field when they leave a comment, the first if gate runs only if there is a @Flagged Mention ! AND the "Waiting on Reply" field is empty, then the ELSE only runs if there is a @Flagged Mention ! AND the "Waiting on Reply" field is already populated. 

Having just written that - I now realize there is one circumstance I hadn't accounted for there. If there was only one person present in that field and they then do a @Flagged Mention ! the automation might run the "IS NOT EMPTY" automation which could break it. The "IS NOT EMPTY" branch also pulls the users from the existing field and merges them with the @Flagged Mentions ! so I can see it also breaking the Remove Commenter branch if the commenter is in that field and leaves a comment tagging someone else, they might not get removed. 

I'll throw a reload at the end of that branch, good catch Bill, cheers!

[Evan Nixon]

Just for anyone that finds this in future - I have caught two bugs here that I've now fixed.
If a flagged mention was followed immediately by another flagged mention the regex would match both as a single string, which merged them together and broke the output to the custom field. This was caused the regex not being precise enough, which I've now fixed :

\[~accountid:.{0,45}\].{0,4}!

The second issue was if a user added a second space between the @mention and the "!" (flag character). Jira by default automatically puts a space after mentions, it's not super obvious that is does this so I think it's a safe assumption that someone will eventually do put that extra blankspace.

Because of the way I had done the .replace("] \!") function with a space between "]" and "\!" an extra space in the comment broke the smart value by no longer exactly matching the string in .remove(). Adding .replaceAll("\\s","") to remove all spaces before .remove(""] \!"") and getting rid of the space between "]" and "!" in the remove function made everything work perfectly.

The fixed Smart Value (with updated regex .match("") function) is now :

{{issue.comments.last.body.match("(\[~accountid:.{0,45}\].{0,4}!)").remove("[~accountid:").replaceAll("\\s","").remove("]\!").asJsonObject("id")}}

One weird idiosyncrasy I've noticed is that the API output of an issue's comments ( as seen at https://[YOURJIRAINSTANCE]/rest/api/2/issue/[ISSUE-KEY] ) shows comments with an exclamation mark in plaintext as "\\!", yet the debug output for {{comment.body}} shows the same as "\!". The .remove("]\!") function wouldn't work if there was actually two, so this must mean Jira internally uses only one backslash to denote a literal character, but the JSON from the API needs two. This gets even more potentially confusing with Smart Values needing a double backslash ( as in .replaceAll("\\s","") with \\s being the token for a blankspace ). Weird.

If anyone wants to give something like this a go, I've done a full explainer on the regex and the logic behind the automation at the link below with an example comment test string. When I started trying to make this I had never used a regex or any of  the ".replace("")" style Java String Class functions, there are a lot late night hours or learning condensed there. Hopefully the total newbie level explanation can help anyone else trying to get something like this up and running. 

https://regex101.com/r/mWhPO5/1

The full automation including a JSON which can be downloaded and imported is on my Github here :

Waiting On Reply Jira Automation (github.com)

[Bill Sheboy]

Evan, for your second-to-last paragraph above there is a third possibility: debug or audit log rule actions alter information to make it presentable.  Your idea of looking at the raw REST API data is probably best when in doubt about what is needed for parsing.

[Mike Espitia]

Hello there, 

I am trying to work something similar to extract from {{issue.comment.first.body}} The phrase that come after Sub Category. to enter into my custom field {{Issue.fields.customfield_10486.value}

[Bill Sheboy]

Hi @Mike Espitia 

As this is an older thread, I recommend creating a new question, and perhaps linking back to this one for context.  That will help ensure more people see the question to offer suggestions.

When you add the question, please include an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected.  Thanks!

Kind regards,
Bill

[Evan Nixon]

What are the chances that I'd be working on re-implementing this feature on a completely new instance, find myself back on this thread (which has been dead for all 873 Days since I last went absolutely insane worked on this thing)...only to find another poor soul starting down the same doomed path I once walked? The universe is a weird place some times.

On an entirely unrelated note:
On behalf of all Jira Admins who have ever stood on the shoulders of the giant that is @Bill Sheboy : I'd like to express my absolute indignant disbelief at the "Rising Star" flair you're stuck with. Bill, you are a Rising Star in the same sense that a Shepard Tone is a rising note. Come on Atlassian. You've finally fixed The Curse of the Spooky View Profile Button , I think it's about time Bill's flair got updated to something more reflective of his years of service to this community. I don't know exactly what you should go with, maybe something short and snappy? Something like "Keeper of Wisdom and Knowledge Eternal"? No, that might get cut off in mobile. Maybe "jirAdmiral of the Forum-Fleet?". Or just keep it simple and classy: "Ya-Boi Bill Sheboy"?

P.S. @Mike Espitia I agree with Bill here: starting a new thread is definitely your best bet. This poor thread has suffered enough, as they always say in my Pedantryaholics Anonymous group: Let it RIP in Peace.