Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,300,749
Community Members
 
Community Events
165
Community Groups

Dynamically assign value to Affected Services field via JSM Automations

Edited

Hello Community

 

Is there a way to copy one field value to another, where source field is text, and destination (to copy it to) is a drop down like Affected Services, or any other Insights field.

The idea is:

My form has a Dropdown of X values, which contain List of Services i want users to use on this form. My Insight Services list contains Y items, thats why I want users to restrict it to be able to select only some of the services.

Via Automation i want to get that value of Drop down list and "Assign it" to Affected Services form field which is and Insights object field.

 

2 answers

1 accepted

@Alex van Vucht (GLiNTECH) thanks for your response.

 

However it does not appear to work, setting value  {{issue.Service Objects.Name}} in the selected Affected Services, does nothing (affected services tries to run autocompletion, nothing is found, and the input box is cleaned up.

Instead, i have selected

  1. When: Value changed for Service Objects
  2. If/else block:
    1. If: Service Objects are empty
    2. Then: Edit issue: Affected Services: Blank, ie. clear this field
    3. Else:
    4. Then: Edit issue: DO NOT Choose fields to set
    5. Click on More options, and under Advanced, specify:
      {

      "fields": {

      "Affected services":[{"id": "{{issue.Service Objects.Service ID}}"}]

      }

      }

       

If you Service Objects field (which is a custom Insights object field type) accepts multiple values, you might as well wanna use Jira's loop-over-list template stanzas: 

{
"fields": {
"Affected services":[{{#issue.Service Objects}}{"id":"{{Service ID}}"}{{^last}},{{/}} {{/}}]
}
}

if you don't want to use loop stanzas we can rather use this shorthand

{
"fields": {
"Affected services":{{issue.Service Objects.Service ID.asJsonObjectArray("id")}}
}
}

this documentation is taken from: https://support.atlassian.com/jira-software-cloud/docs/advanced-field-editing-json

Hello,

For the sake of others who may (by miracle) find this post, some helpful links and hints:

1) Please see and vote on this feature request: https://jira.atlassian.com/browse/JSDCLOUD-10340

Affected Services though it looks like an Insight Object custom field, and has an Insight schema backing it up, is in fact using Opsgenie API and Opsgenie's service id's for the items. Thankfully Opsgenie service id is stored in the Insight object as an attribute.

We had to use "loop stanzas" as the "shorthand" notation didn't work, kept successfully getting some numeric id value, instead of the Opsgenie Service ID attribute.

2) In our case the duplicate Insight Object custom field Services Affected is based on the same Insight schema, and is presented on the Issue Create scheme, together with dependent Insight Object custom fields.

Automation on create syncs the value to Affected Services.

3) Please note, the Affected Services field does behave differently in UI than the Insight field based on the same Insight schema, as it shows mode details from JSM/Opsgenie, so we preferred to keep that field on the edit and view screens, and hide the "parent" Insight field from these, only displaying it on create screen for the purposes of dependent drop-down functionality.

This does however then require addition setup in Automation to keep Affected Services and the "parent" Insight field in sync in the other direction, so if the affected service changes later in JSM ticket workflow, the dependent Insight field displays correct objects that correspond to the "sub-options". This automation rule is configured to run on Edit and Transition, and not be invoked by other rules.

Obviously, none of this is instantaneous, and is just one major kludge for something that should be so simple, and could have been avoided if the dependent Insight custom field could be dependent on Affected Services directly. 

I've been doing some work with the Affected Services field recently and it's a little special. It uses the OpsGenie API, not the Insight Cloud API.

You'd have to create a separate Insight Object custom field for the Services schema so that you can then set an IQL query to restrict the options. I'll call this field "Service Objects" but you can call it whatever you like.

Try this:

  1. When: Value changed for Service Objects
  2. If/else block:
    1. If: Service Objects are empty
    2. Then: Edit issue: Affected Services: Blank, ie. clear this field
    3. Else:
    4. Then: Edit issue: Affected Services: {{issue.Service Objects.Name}} 

I'm not too sure how well this will work if multiple services are selected. Working with smart values for multiple selections gets messy, especially with Insight objects. Get it working first for a single selection then expand from there.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Service Management

Improving the Create Issue Experience in Jira Service Management Cloud

Hello everyone!  We are very excited to announce some much needed changes to the issue create experience in JSM (the blue "create" button) at the top of the screen.  We have just starte...

190 views 7 6
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you