Prevent changing a "check-box" field using automation

[Stephen Pheiffer]

I'd like to prevent certain users from changing a field of type "check-box". I've set up a rule to detect field changes and react based on the user. This correctly detects and reacts to field changes and I can successfully for the value to be a constant after a change.

However, I want to set the value, back to what it was previously, not a constant. I've tried:

{{fieldChange.from}}

{{fieldChange.fromString}}

It does not work and instead the field gets set to null. I have read other posts, and this seems to work for other people with other fields, but maybe the field type is the problem?

I've also tried these suggestions:

[{{fieldChange.from}}]

"{{fieldChange.from}}"

but JIRA interface would not accept them as legal.

Any ideas?

[Trudy Claspill]

Hello @Stephen Pheiffer 

Can you show us the entire rule you have constructed so far?

If you are using the Field Value Changed trigger then you can use the {{changelog}} smart value to reference the changed field To and From values.

In this example I am printing the values in the Audit Log for the rule.

To set a checkbox field you have to use the Advanced Editing with JSON option.

https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Checkbox-custom-field

What makes this more complicated is that I assume you will have a variable number of checkboxes checked. You would need to be able to parse the fromString to find the names of each check box that was selected, and then find a way to set each of those check boxes. I don't know if conditional logic can be implemented in the JSON to deal with the results. I've never researched if that is possible or how to do it.

Alternately there may be a way to create a loop over the values in the fromString. I haven't had time to figure out if or how to implement that.

[Stephen Pheiffer]

Hi, thanks for looking into this. Here is an example of a working rule, operating on a field of type "number". This was constructed by looking at various examples/posts elsewhere.

If I change the rule to operate on a field of type "checkbox" (something with multiple items that can individually be checked on/off), then the rule no longer works. I've also tried using {{fieldChange.from}} which should evaluate to the raw data type...this doesn't work either.

Are you familiar with the API/language in use here? What does {{blah}} mean? What kind of expression is expected for the "edit issue - set field" input? Is this supposed to be a string? If so, why would {{fieldChange.fromString}} be accepted for some data types, but not for others?

Any information you have would be appreciated. Thank you again!

[Trudy Claspill]

When setting field values in the Edit Issue action the system expects you to provide an explicit value or an expression that equates to a valid input value for the field. 

I don't know the language behind the interpretation of the expressions that can be used.

{{blah}} in this context is what Jira refers to as a Smart Value. It can be a reference to a field in an issue, a data structure, a calculation,.... There are a lot of ways smart values can be used.

{{fieldChange.fromString}} would be accepted for when the content of fromString represents a value that is a valid value to assign to the field. In the case of a checkbox field, if fromString contained multiple values they would appear as a comma separated list. When attempting to assign a value to a checkbox field through the Edit Issue action, a comma separated list is not a valid method for assigning the values. Values for a checkbox field can be assigned only through Advanced Editing with JSON.

[Stephen Pheiffer]

I tried using the "Additional fields" section as recommended, but it doesn't actually change the field. Here was what I tried:

{
"fields": {
"Instrument": [{ "id" : 10024}, {"id" : 10036}]
}
}

This doesn't really make much sense to me. For example, how would I even specify a value for "fields" based on what the previous value was? Even if I could, how do you make "Additional fields" section actually run?

[Stephen Pheiffer]

OK, I found out that there was an error with the above (just learned that it sends you errors in email). The following allows me to set a checkbox field to a fixed value:

{
"fields": {
"Instrument": [{ "id" : "10024"}, {"id" : "10036"}]
}
}

Still not sure how to set it to the value I want, but this is something.

[Ken McClean]

You might be able to pull the original value of the field from the change history manager, and set it to that.   I'm certain there's probably an easier way to do it, but that may be one avenue worth exploring:

https://docs.atlassian.com/software/jira/docs/api/7.6.1/com/atlassian/jira/issue/changehistory/ChangeHistoryManager.html


Edit:  I don't know why my brain thought this was in reference to you writing a listener. Ignore me!

[Stephen Pheiffer]

That looks like a Javadoc. Is there some way to just code this in Java? If so that would be great. I don't know anything about the {{language}} being used in JIRA.

[Ken McClean]

ScriptRunner uses Groovy and the Jira Java internal libraries to extend the functionality of the product. It's fantastic, and I don't say that simply because I work for the company that makes it. Without the ScriptRunner plugin, however, you're stuck with the smart variables.

[Stephen Pheiffer]

Ahh, I see. I haven't even scratched the surface of this product yet and I'm using the free version. Not sure about plug-ins or anything else. Will look into that later.