Can i have seperate IQL for insight custom field on portal side and jira side?

[Kevin Gérard]

I'll be using Insight objects to help my servicedesk set reporters & organizations for their tickets (and include meta data). 

These fields will be filled in from the portal. 

however, i want the fields to filter out differently on portal side, then in issue view side. 

is it possible to set seperate IQL filters to support this behaviour? 

[Mark Segall]

Hi @Kevin Gérard - My initial reaction is no.  You would need a separate insight field for internal vs portal, but can you please provide some context into your situation?

[Kevin Gérard]

Hi Mark, 

I thought so too, so i'm experimenting with that now. i got it working though, but it's quiet  'ugly' as the portal fields are also visible in the portal request section (even after clearing them). means both versions of the field are available. 

to give a bit more details, i will manage Customers & Organizations via INSIGHT. 

Both have matching custom fields to be used in the portal & in the issue view. 

in the portal, i want the fields to be filtered based on the signed in user,

That means a specific IQL in the filter section, so my users cannot log tickets in someone elses name.  (an agent could, becuase he can update the Reporter field!) 

IQL "Linked user" = currentReporter()

Linked user is a attribute that holds the actual user. 

for Organization it would be something like this: 

object having inboundReferences(objectType="Customer" AND "Linked User" = currentReporter())

-> user must be set as a member of that organization

this works quite well for the portal view. 

BUT 

if my agent wants to make changes in the issue view, he too will be bound by these limitations. which has a blocking effect. 

i need my agent to freely pick an organization object & then select a reporter that matches it. 

functionally this works, but i cannot seem to get it 'clean' UI wise (which for me is important too)

hope this helps. 

any tips?

[Kevin Gérard]

@Mark Segall 
ideally i'd be setting a second filter here 

one for portal use, and one for issue view use...

[Mark Segall]

I've had similar configurations for customer/organization.  However, I never had the use case where the connection between Organization/Customer needed to be broken.  

If it's a matter where the user can be associated with multiple organizations, you can change the Organization issue scope to be something like this:

object having inboundReferences(objectType="Customer" AND "Linked User" = ${customfield_xxxxx})

xxxxx = the custom field value of the customer field selection

This would only make the selection of the user based upon the current user, while the Organization would be based upon the selection of the Customer.  This enables the reporter to still be bound by only Organizations they're explicitly tied to, but the agent would now have the ability to change the Organization based upon the Customer field rather than their personal account.