Portal - Determine Customer Request Types and visible fields using Insight data

[David Harkins]

Does anyone have the same or similar use case or know of a way this could be achieved?

We use Insight as our CMDB, recording, what Services, Applications and components each of our customers have.

We need to be able to present the available request types to service users based on the services they are subscribed to, We already have a duplicate list of Organizations in Insight, along with the JIRA Organization ID, so can display more organizational information on the Issue screens.  But we are no ready to go one step further.

Our organizations are split between hosted and on-premise, so if hosted, we have all the detail of there environments and would like to present this to the user to select the appropriate object / CI.

The only way I could think of moving this forward is by the use of JIRA groups, but this would required some automation to update JIRA groups as insight data is updated etc.

[Wim Abts]

Hi @David Harkins , 

We're also looking to link the Jira organization to an Insight organization and this way link the created support ticket to the info on the customers set-up in Insight.
We're just starting so i'm interested to know how you managed to do this.

Can you give me some info on how you actually made this work?

Thanks!

[David Harkins]

Hi @Wim Abts 

Sure, I'll try my best to explain what we have.

First an Organization Object in your scheme, We have a 'Service Desk' schema for this.

You will obviously need a Name attribute, but also a 'JIRA Service Desk ID' attribute.

When you add an organization, you need to also add the Service Desk ID which is derived from the Customer section in the Service Desk Project, i.e.: https://###.###/projects/JIRA/customers/1234

Selecting an organization will show you the ID in the URL, or you can hover over them to get them.  You can get them all using the API but that would be another day.

We then have scriptrunner and automation for when an issue is created or the organisation is changed to set / update the field 'Organization ID' to the ID of the Organization.

Then an Insight Object field type 'Organization Info' then uses IQL to set the matching object based on the Organization ID.  Once the Organization Info is created you can display any attribute from the object on the issue screen.

We do go one step deeper and show other linked objects if they exist, like what services the company has subscribed to.

Which brings me back to the original question, if a customer with a linked object has a 'Hosted services' then we would like to display different fields on the portal.

If a customer does not have hosted services, the respective fields would not make sense.  We could ask the customer if they are hosted, but as the service provider, we know if they are or not.  Just need the request forms to represent that.

[Wim Abts]

Hi @David Harkins , 

Thanks for the info, any change that you could provide me the scriptrunner script to set used in the automation rules? 

[David Harkins]

This is what we use:

import com.atlassian.jira.component.ComponentAccessor

//Get Organizations
def value = issue.getCustomFieldValue(ComponentAccessor.getCustomFieldManager().getCustomFieldObject(10110));

//Get the ID of the first Organization
def OrgID = value.id[0]

// Custom Field ID - 11602
final customFieldName = "Organization ID"

def customFieldManager = ComponentAccessor.customFieldManager
def customField = customFieldManager.getCustomFieldObjects(issue).find { it.name == customFieldName }

issue.setCustomFieldValue(customField, OrgID.toString())

[Wim Abts]

Thanks, I got that part working now.

Struggling to get the link between the issue and the Insight Object now, the Mindville documentation is offline en the Atlassian documentation is not quite as complete (yet).

Can you show me the definition of the Insight Object 'Organization Info'?

[David Harkins]

@Wim Abts 

This is how we have ours.

[Wim Abts]

Thanks!
Did you ever encounter that the Scriptrunner plug-in in Automation gets disabled?
This happened to us a few times now on our Test environment, only way to resolve is to restart the Jira node...
Just makes us wonder about the stability.

[David Harkins]

@Wim Abts 

We've never had an issue with Scriptrunner, on a Data Centre install.

In fact we are moving more towards script runner to replace a number of the quick automations that were added using the Automation for Jira app.  Which has a tendency to throttle requests.

[David Sumlin]

I’m also a little confused what you’re trying to do regarding request types.

it sounds like if you can determine if the requestor is an on-prem customer or a cloud customer (presumably by verifying the organization against your Insight metadata), you could use a behavior to show/hide the appropriate fields.

[David Harkins]

Do the behaviours work in the customer portal?

[Dirk Ronsmans]

Hi @David Harkins ,

I'm blocking right now on the following:

We need to be able to present the available request types to service users based on the services they are subscribed to

When you are talking about the available request types do you mean the possible request types they see on the portal? (so not a limitation on a field, but what request they can submit)?

If so, that won't be possible without an app, there is no way to limit the visibility of a request type (unless you want to block it using a scriptrunner validator upon submitting)

There are apps out there that allow you to limit the visibility of your request types but I'd like to  clear up what you exactly want to do first :)

[David Harkins]

Hi @Dirk Ronsmans 

Ideally this would be both, request types first, then fields as we progress.

We do have a plugin to accommodate visibility but as mentioned this only done via a service users group membership, which is not ideal as it would be too great an admin overhead.

[Dirk Ronsmans]

Well I believe fields or at least field values shouldn't be an issue with an Insight reference field.

Those request types are a lot harder.. like I said, out of the box there is nothing builtin.

If you have a plugin that can do it you'll have to go with that one even if the overhead is a lot.. 

There is a suggestion open for it (https://jira.atlassian.com/browse/JSDSERVER-195) but nothing that will be implemented short term.

[David Harkins]

If I can elaborate on the field requirement.

We provide services for two types of users, for those that are hosted by us we want them to be able to select the server details from the insight object type.

Those that are not hosted, should not see the above field as there would be no insight objects to display, instead they should see a free text field with which to populate the server details in manually.

Presenting both would lead to confusion for customers and agents.

[Wim Abts]

For hiding some request types, maybe this is an option (Data Center only)
https://docs-fb.appsvio.com/v/data-center/customer-features/access-configuration/request-types-access

[Kate Pawlak [Appsvio]]

Hi,

Thank you @Wim Abts for mentioning our app Feature Bundle for Jira Service Management. Unfortunately, hiding request types depending on conditions is available only for server / data center. Due to current limitations, we, as an app creator, are not able to develop a such feature for JSM cloud :( 

Btw, the correct link to the documentation mentioned above is here (we changed the URL in the meantime).

Best regards,

Kate