Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

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,460,447
Community Members
 
Community Events
176
Community Groups

Announcing Filter Issue Scope for Insight

A common question we get from people familiar with Insight on Server/DC is when will will Insight for Cloud support the ability to dynamically filter Insight custom fields.

Well, good news! Filter issue scope and placeholders are now available for Insight custom fields as part of the integrated version of Insight for Jira Service Management.

If you’re not familiar with filter issue scope, and wondering what on earth I’m on about, let me explain.

 

What is filter issue scope?

It’s a configuration option for Insight custom fields that lets you filter the objects shown in the custom field based on other values in the issue. This is done with a combination of IQL and placeholders that pull in the current reporter, assignee, project, summary, due date, custom field values etc.

And it works in the request portal too! You can dynamically filter Insight custom fields based on what’s already selected.

 

Why is filter issue scope useful?

Let’s say you have a list of laptops in Insight with an owner. When an employee wants to submit an issue involving their laptop you can have a custom field showing the laptops.

Without filter issue scope, the employee will see a list of all laptops, including those belonging to other people. With filter issue scope, you can make the custom field only show the laptops that the employee is the registered owner of which is much more user friendly.

 

Example configuration:

How to configure - we set the filter issue scope to only show laptops with an Owner whose Jira User account matches that of the reporter of the issue.

”Owner” is an attribute on the “Laptop” object type in Insight which links to an “Employee“ object type.
”Jira user” is an attribute on the “Employee” object type that stores the Jira user profile of the employee.

 

Screenshot 2021-06-30 at 13.32.17.png

 



In Action:

 

Filter issue scope.gif


Other Examples:

Another example use case is for requesting new hardware. For example, if the requestor selects a model of laptop they want, another custom field can be used to show all laptops of that model type that are in stock in your inventory. So the agent doesn’t need to go into Insight to check available stock.

In this configuration, customfield_10236 is our custom field where the customer selects their desired laptop model. 

Screenshot 2021-06-30 at 13.31.50.png


Other common use cases for this, is to have a series of custom fields that narrow down a selection. For example, if you select an ‘affected application’ a following ‘affected infrastructure’ custom field could be set to only show configuration items that are related to the selected application.

11 comments

Fantastic news!  am I right to understand that filter issue scope does not work in automations yet?

Mikael Sandberg Community Leader Dec 03, 2021

Does this also work with hidden fields on the form? Our use case would be to have a hidden location field and then use that to filter out what objects the user should see. That would allow us to use the same field on different request types based on location.

Like Dirk Ronsmans likes this
Dirk Ronsmans Community Leader Dec 07, 2021

@Mikael Sandberg , @Charlotte Nicolaou 

I've currently got a couple of support tickets open for it. It seems that a hidden field does not have it's value already set on the screen but get's the value when the form is submitted. So for me the value doesn't get added in my query.

However, even when it's not hidden it still doesn't seem to get the value or at least it doesn't work as expected (for me) with select or text custom fields. (but maybe I'm missing on how to get the value from the field and it's different than using the placeholder ${customfield_xxxxx} ?)

i'm still hoping they will allow me to just add a (hidden) text field on my request form that contains my entire query so I can really filter the field based on the Request Type.

Lastly, it does seem to work fine with visible Insight fields that are referencing each other but you can't hide a Insight custom field on Cloud which also means, no default value..

So the basic functionality seems to work "referencing 2 insight custom fields between eachother and also some predefined placeholders like reporter" but other than that the more exotic use cases stump me.

Like # people like this

yap, I also have the same question , I need filter insgiht object by Request Type . but event is set the default value on it for hidden field or use scriptrunner set the default value . 
the insight object filed can't work before the ticket created. 

I've been trying to use this to get the manager of the reporter but it doesn't seem to be working. Any ideas about how to do this?

Pretty stupid that the "raise this request on behalf of" doesn't display on a customer user, only agents!!

AQL to custom field doesn't work

The last information I had was that the filter function only works with other assets (insight fileld). Is there any change here in the meantime?

@Daniel Ebener 

 

I have an Insight field filtering on a select list, you just have to have the same string attached to your object at the Insight end

 

Insight field Name - Development Team:

object having outR(Name in (${customfield_11503.name${0}})) and Active = True

 

I have a select field called Queue, I have an attribute in my Development Team Insight object type called Queue, the attribute is pointing at another Insight object type called 'Queue'. basically I 1:1 map the options I have in the Queue field, to objects in the Queue object type at the Insight side. So when someone selects the Queue in the Queue select list field, it refines the Development Teams in the Development Team Insight field

standard customer users do not have access to the field raise request on behalf of.  The AQL doesn't work on custom fields as I raised this last October and still awaiting it to be fixed.

Yeh it's a big shame reference fields and IQL referencing or placeholders in general don't work for hidden fields on a portal form, I do imagine now it's integrated with JSM that we'll see a lot of improvements. Personally I'd also like to see the post function conditions have the option to use jql instead of just Groovy, especially as it doesn't even support Groovy expressions and requires the full script, I just use JMWE instead, way easier.

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events