nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

All comments

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.

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.

Wim Abts_desah7

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.

David Harkins

Do the behaviours work in the customer portal?

Wim Abts_desah7

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())

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

insight

portal

jira-service-management

jira-service-management-server