Fundamental linking between JIRA Service Desk User Account and Riada Insight User Object

I have a question on the fundamental, architectural, interoperation between JIRA Service Desk (JSD) and Riada Insight – specifically with respect to the user. There are two: the JSD user account (which, for us, is synced from Active Directory (via LDAP) and the Insight ‘User’ Object Type. For our purposes we created a ‘User’ object type in Insight, and that object type has an attribute (field) of ‘Email’ which is of type ‘User’ using a group called JIRA_SERVICEDESK_CUSTOMERS (all our users from AD) which links to the JSD user account.

 The key question is how does Riada setup Insight to work with JSD so that JSD user account information (stored as an attribute in an Insight Object Type) can get back into JSD? How is the interoperation between the two systems designed? We currently are running JSD 3.8.1 and Insight 5.1.3.

Currently we maintain all user information in Insight, in the ‘User’ Object Type. The JSD user account is used solely as the account accessing the system, and obviously as the user in JSD.

Relationships between Object Types (for example like Users, Applications, Servers) are done via the Insight User Object. So if there is a ‘System Owner’ field (attribute) in the ‘Servers’ Object Type then it is chosen as an Insight User Object – not a JSD user account.

So, essentially, the JSD user account information is listed in the ‘Users’ Insight Object Type , but all relationships in Insight are done using the ‘native’ Insight user.

We have successfully setup custom Insight fields in JSD such that when a request is raised the special ‘Reporter’ user (the JSD user account) connects to the Insight ‘User’ so that the custom field is filtered to the specific Insight user. That part is OK. The question then comes if we need to reference a second user, for example:

  1. An Insight user has a manager, the manager field (attribute) is of type ‘Object’ (not JSD User) which references back into the ‘User’ Object Type (table).
  2. In the ‘Servers’ Object Type there is a field ‘System Owner’ of type ‘Object’ (again not JSD User) which references back into the ‘User’ Object Type (table).

If we setup all fields that refer to users as Type ‘User’ and point them to the JSD user directory instead of pointing them to the Insight ‘User’ Object Type then we would lose the linkage and relationships between all the Insight Object Types – which we don’t want to do.

But, as I understand… JSD needs to list JSD users in Service Desk requests because they are the users listed in the User Directories and that is needed for login, assigning permissions, emailing and so forth.

Say, for example, we have a Service Desk Request type needing Manager approval. We have to put the JSD user account into the Approvals field, but we have the relationship in Insight using the Insight user object. So if we know the user is ‘A’ and their manager is ‘B’ how do we retrieve the user ‘B’s JSD user account name (which is in the Insight User

So how do we get the JSD user information from a linked Insight field, if an Insight user has a manager which points back to the User object type how do we lookup the manager and then retrieve their JSD user account information.

4 answers

0 votes

Hi Patrick,

I've answered you on our internal service desk about this.

Best Regards
Alexande

We have the exact same setup and problem, what was the solution to the issue?

Sidenote: Answering a community question privately somewhat defeats the purpose of a community.

 

EDIT: Taking a break to post this did some magic so it's no longer a problem.

for fear of doing a 'me too!' post,

 

I'm having a very similar issue and agree with Daniel, please post the solution to the community so others can benefit.

Any chance of a public response? :)

Yes, as the original poster I second that request.

I heard that Raida, the developers of Insight, had made some improvements/enhancements in this regard but (to be honest) so far am so busy have not been able to investigate/confirm.

I think it would be good for Atlassian - as the owners of JSD - to 'step up to the plate' and give customers a clear answer and even a detailed HOWTO document on this. The point is that Riada Insight is, realistically, the default CMDB for JSD and I do not believe that Atlassian is ever going to build their own. Which on one level is OK - if Atlassian would work closely with Riada to get a good, workable, clean solution for customers,

Sure it's risky in some ways for them because they don't own (control) Insight but... please... think of your customers.

I'll take a stab at this as I think we are using it very similar to your description.

 

Some Terms we use to help me lay this out:

JIRA Login = LDAP synced accounts used to log into JIRA / Customer Portal. AD groups are used for setting access/permission

User Record: User object in Insights, we as well have an attribute that links it to a JIRA Login. We do this automatically each night using the Insight Imports. We run two, one is a user import from JIRA, then we do a secondary LDAP import using the login name as a key to fill in information on the object such as phone, manager, dept, etc. 

 

For Approvals specifically, we made this work via an insight script in the workflow. We transition an issue to a Pending Approval status and in that transition run an insight script that looks at the "Requested For" field which contains a User Record with a Manager attribute set to another User Record. The Insights API documentation is pretty good but below is a general idea (i don't have access to the actual code this very moment). So after that transition the script has set the approver field to the managers JIRA Login and then we have it email that user.

 

Note: this code is sloppy, but a general idea of how you could get the JIRA account from an object that is referenced from another object

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.ComponentManager;
import com.riadalabs.jira.plugins.insight.channel.external.api.facade.ObjectFacade;


def customFieldManager = ComponentAccessor.getCustomFieldManager();
Class objectFacadeClass = ComponentAccessor.getPluginAccessor().getClassLoader().findClass("com.riadalabs.jira.plugins.insight.channel.external.api.facade.ObjectFacade");
def objectFacade = ComponentAccessor.getOSGiComponentInstanceOfType(objectFacadeClass);


def requestedForField = customFieldManager.getCustomFieldObject('customfield_11500') //Requested For Insights field
def requestedForFieldVal = issue.getCustomFieldValue(requestedForField)

def manager
def managerObject
def managerAccount

if(requestedForFieldVal ){
manager = objectFacade.loadObjectAttributeBean(requestedForFieldVal[0].getId(), "Reports To")
if (manager) {
if (manager.getId() ){
managerObject = objectFacade.loadObjectBean(manager.getObjectAttributeValueBeans()[0].getValue())
if (managerObject) {
if (managerObject.getId() ){
def managerJiraAccount = objectFacade.loadObjectAttributeBean(managerObject.getId(), "JIRA Login")
managerAccount = ComponentAccessor.getUserManager().getUserByKey(managerJiraAccount.getObjectAttributeValueBeans()[0].getValue())
}
}
}
}
}
managerAccount


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Aug 13, 2018 in Jira Service Desk

Jira Service Desk – Don’t be afraid, the journey begins with curiosity!

...be more productive while being fun to use at the same time. For some, getting started can be a bit intimidating. This is especially true if Jira Service Desk is your first exposure to Atlassian...

37,441 views 13 39
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you