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:
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...
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!
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