Automation: Value added to one field removes from another.

[Darrin Lillian]

Hi!

I have custom fields "scope" and "descoped" that are multi-select checkboxes that have the same options.  I would like to create an automation that removes anything added to the descoped from the scope field.  

EX:

Scope: Web, Server, API

Descoped: API

Automation will remove API from scope.  I have been trying this, but I get an "Not valid JSON" error.

{
"update": {
"scope:":[
{"remove": {{issue.descoped.value}}
]}
}
}

Another one I tried with same result.

{
"update": {
"scope:":[
{"remove": {"value":{{issue.descoped}}
]}
}
}
}

Massive amounts of searching has not lead to me to an answer and I am hoping someone in the community can help me out.  TIA!!

[Darryl Lee · Accepted solution]

Hey @Darrin Lillian I recently answered something similar with help from @Bill Sheboy:

• How to add (copy) values from checkbox to labels (update not set) using automation EDITED 

OOF sorry for the previous version of this answer where I foolishly posted untested code.

This time I actually tested, and this version (with nice indents) works:

{
  "update": {
    "scope": [
      {{#issue.descoped.value}}{"remove": {"value": "{{.}}"} } {{^last}},{{/}}{{/}}
    ] 
  }
} 

@Ste Wright  you were very close. I think you were on the right track with asJsonObject, but I just created the "object" manually. Maybe I'll see if I can use that function within the iterator like you tried. But the above should work for now.

[Darryl Lee]

I should also probably add a note here saying I don't quite understand the use case.

If something is out of scope, then isn't that visible by seeing that it is unchecked?

OH WAIT. STUPID NEW ISSUE VIEW HIDES UNCHECKED BOXES.

BOOOOOOOO. Ok, now your use case makes sense. 

Also, it is super-annoying that you have to do this, if this is why you are doing it.

[Darryl Lee]

Another question @Darrin Lillian - will you be creating a corresponding rule where if somethings is removed from Scope, it gets added to Descoped?

My only worry here would be if two people are editing the different fields at the same time, you might run into a race condition.

Or are you planning to have Scope be a read-only field? I guess that would probably take care of that.

OH oh, the other thing I was wondering. What if somebody wants to *uncheck* something they have Descoped. Will you be putting that back into Scope?

I guess this rule would trigger off of "Value added" and you'd need a second rule to trigger off of "Value deleted". 

The tricky thing is that both could be true. That is, somebody could check and uncheck several different options, and to account for *that* you would have to look at the {{fieldChange}} smart value and ugh, figure out the logic to flip the option correctly based on whether it was added or deleted. It's a little late for me to figure that one out. Maybe in the morning. :-}

[Darryl Lee]

Ok, here's how to do it with the asJsonObject function:

{
  "update": {
    "Checkboxes": [
      {{#issue.Not Checked}}{"remove": {{value.asJsonObject("value")}} } {{^last}},{{/}}{{/}}
    ] 
  }
} 

Hm. I think I prefer my original version. Easier to read and understand. 

[Darryl Lee]

[Edited to resolve the extra comma issue when only adding or removing adding checks, not both.]

Ok, found a fix for my use case:

OH oh, the other thing I was wondering. What if somebody wants to *uncheck* something they have Descoped. Will you be putting that back into Scope?

Here it is:

{
  "update": {
    "scope": [
      {{#deletedFieldChange.values}}{"add": {"value": "{{.}}"} } {{^last}},{{/}}{{/}}{{#if(and(deletedFieldChange.values.size.gt(0),addedFieldChange.values.size.gt(0)))}},{{/}}
      {{#addedfieldChange.values}}{"remove": {"value": "{{.}}"} } {{^last}},{{/}}{{/}}
    ] 
  }
} 

So again the caveats: I'm assuming that the scope field starts out with all options checked. And also that nobody is touching the scope field (you can create a View Screen with it and then remove it from the Edit Screen, as described here).

Also: For the trigger, I'm simply checking for "Any changes to the field value" of Descoped, because now we can handle both added and removed options. 

[Ste Wright]

Hi @Darryl Lee 

Awesome!

I found this answer worked well with the rule, although the additional ideas are also great :)

Ste

[Darrin Lillian]

@Darryl Lee Fantastic!  Thank you! 

[Darryl Lee]

Hey @Darrin Lillian - I hope this helps. I am very curious whether you'll be able to use it, and if you can clarify that every issue starts with all 50 Scope options checked.

Also, it it pertains to my little rant the other night, I'd love to see what that looks like on the screen.

Also, wonder if you will use the latter code I wrote which handles the case if users later uncheck options that were Descoped.

[Darrin Lillian]

@Darryl Lee yes, this helps tremendously.  I am currently testing the last code you wrote which handles the unchecked values as well.  I was trying to go from A to C and you went all the way from A to Z.  🥳

The scope field does not have all 50 items checked at the beginning.  There are core features which just about every client will use, but some items in the scope field are just different ways of doing the same thing.  For instance, their front end display can be done via a hosted solution or API.

[Darryl Lee]

Ah thanks for context.

So if you are only defaulting to say, 10 core features at creation, will you be also be defaulting the other 40 options in the Descoped field?

Just thinking about keeping the two fields "in sync".

And is the plan to keep Scope as read-only? Because if not, as mentioned before, I think you'll need to create a "companion" rule that updates Descoped when Scope is changed.

But anyways, so happy to hear it's going to work for you. It was pretty cool to figure out the final fix.

[Ste Wright]

Hi @Darrin Lillian 

I've got halfway there - I recreated this setup, and I can remove a value from "Scoped" if it's set in "Descoped" - but only if Descoped has a single value.

The JSON looks like this:

{
"update":{
"Scoped":[
{
"remove": {"value": "{{issue.Descoped.value}}"}
}
]
}
}

^ But as soon as Descoped has two values, it still errors. I haven't found a way to set multiple values using the smart value. I did try using asJsonObjectArray(keyName) - but couldn't get it to work - see this help page for more information.

---

How many options are in your checklist?

There might be an alternative approach you could take, depending on how long the checklist is :)

Ste

[Wojciech Wardaszko _HeroCoders_]

@Darrin Lillian @Ste Wright 
In these cases, the Log action comes very handy for debugging. you can store values used in your JSON to see what they actually hold and why it breaks.

Also, my idea would be to use the Issue field value changed trigger and use the {{fieldChange.fromString}} with some conditions to update the relevant fields. Something like this:

Trigger: Field changed
Field:Scope
for: value removed

Condition:
if:
{{fieldChange.fromString}} contains API

Action: Edit issue

Field: Descoped
add API

This obviously is only viable if the checklist does not change from issue to issue and it means a branching if for every possible value in the Scope checklist, but seems more reliable than web requests that tend to fail in the most unexpected ways, at least for me.

You would need another automation to trigger on changes in Descoped. Should be possible to copy the first rule and adjust easily.

Cheers,

[Darrin Lillian]

@Ste Wright  - there are about 50 options in implementation scope. 

@Wojciech Wardaszko _HeroCoders_  - the options do not change from issue to issue to issue.  

I will see if I can work off of what you two have provided.  If you have any further breakthroughs, please share and I will too!

Thank you!

[Ste Wright]

Hi @Darrin Lillian 

Thanks for confirming the number of options.

My alternative approach was going to be similar to Wojciech's - it would look something like this:

• Trigger: Field Value Changed
  • Field to Monitor = Descoped
  • Change Type = Value Added
• Branch: Related Issues
  • Type = Current Issue
    • Branch-Condition: Issue Fields Condition
      • Field = Descoped
      • Condition = contains any of
      • Value = Option 1
    • Branch-Condition: Issue Fields Condition
      • Field = Scoped
      • Condition = contains any of
      • Value = Option 1
    • Branch-Action: Edit Issue
      

      • {
        
        "update":{
        
        "Scoped":[
        
        {
        
        "remove": {"value": "Option 1"}
        
        }
        
        ]
        
        }
        
        }

• Branch: Related Issues
• Type = Current Issue
  • Branch-Condition: Issue Fields Condition
    • Field = Descoped
    • Condition = contains any of
    • Value = Option 2
  • Branch-Condition: Issue Fields Condition
    • Field = Scoped
    • Condition = contains any of
    • Value = Option 2
  • Branch-Action: Edit Issue
    

    • {
      
      "update":{
      
      "Scoped":[
      
      {
      
      "remove": {"value": "Option 2"}
      
      }
      
      ]
      
      }
      
      }

• ...etc

---

A few notes on this alternative rule:

• The rule would need 50 versions of the Branch, one per option. Due to Automation Service Limits (65 components per rule), you might need multiple rules to make this work
• The Branches are required to split each set of Conditions/Actions from the rest - otherwise, if the first condition was for "Option 1" and that option was not populated in both fields, the rule would fail before reaching "Option 2"

---

This might not be the optimum option - but it does work.

If you do find a more optimum solution though using the original rule and smart values for multiple values, let us know!

Ste

[Darrin Lillian]

Thanks for your input.  I am still experimenting with ways to do it.  I have tried the JSON object array and several other ones mentioned on the link that you gave me without success. 

I may have to look at which values historically get descoped the most and see if there is a way I can narrow the options down so I don't have to do 50 of them.  There are some items which should NEVER be descoped so hopefully that can save me some work.

[Darrin Lillian]

I found this...wonder if it can be modified to fit my use case?

https://community.atlassian.com/t5/Marketplace-Apps-Integrations/How-to-copy-multi-value-field-in-using-Advance-Options-in/qaq-p/769692 

[Ste Wright]

Interesting! I also found this: https://community.atlassian.com/t5/Jira-Software-questions/Automation-Advanced-field-editing-JSON-add-multiselect-values/qaq-p/1934405

I tried to replicate the two rules, but after quite a bit of testing I'm still getting an error.

I ended up with this:

{
"update": {
"Scoped" : [ {{#lookupIssues}}{{#Descoped}} {"remove": {{value.asJsonObject("value")}} } {{^last}},{{/}}{{/}}{{/}} ]
}
}

And another option, this:

{
"update": {
"Scoped": [{{#lookupIssues}}{{#Descoped}},{"remove":{{value.asJsonObject("value")}}}{"remove": "{{.}}"}{{/}}{{/}}]
}
}

And the error for both of them:

Additional fields contains invalid 'update'. You can use 'add', 'remove', 'set' or 'edit' for operations.

customfield_10123

Hopefully this moves you closer to the answer!

Ste

[Darrin Lillian]

I have tried so many variations without success.  I also did the long version, but we decided to not go that route after several times testing.  Looks like people will have to update their own fields until I find a working solution. 🤷‍♂️

[Ste Wright]

Hi @Darrin Lillian 

I reached out to the other Community Leaders - @Darryl Lee has posted a solution that I find does work!

Ste

[Darrin Lillian]

I have tried so many variations without success.  I also did the long version, but we decided to not go that route after several times testing.  Looks like people will have to update their own fields until I find a working solution. 🤷‍♂️