Comment visibility - an advanced issue sync case

[#1]

Introduction

One of our customers is using Exalate for an advanced use case, where comments need to be handled differently based on the context where they are created.

Challenge

There are 2  instances and 4 projects at play

• External Instance (label JSD)
  with one service desk project
• Internal Instance (Label INT)  with 3 projects
  Internal  service desk and 2 dev projects: dev project A  and dev project  B

Requirements

The comment related requirements are

• Comments on the external service desk need to go to the internal service desk and ripple through to the dev projects
• Comments on the dev project(s) should only go  to the internal  service desk project but not to the external service desk
• Comments from the dev project on the internal  service desk must be restricted, while the comments  from the internal service desk on the dev project must be open
• If a comment is  made  on dev project A, then  it should not ripple through  to  dev project B or the original  ticket (on the external service desk)

Understanding the challenge

There are thus 3 types of comments

• Ticket comments made by customers on the external service desk
• Service Desk comments made by support engineers on the internal service desk
• Dev comments made by developers on the dev project

This table depicts the required behavior whenever a comment is made on one project, how it needs to be synced to the twin issue
(The column is the source)

Filtering out the comments which should not be exchanged 

To meet the requirements

• Comments on the external service desk need to go to the internal service desk and ripple through to the dev projects
• If a comment is  made  on dev project A, then  it should not ripple through  to  dev project B or the original  ticket
• Comments on the dev project should only go  to the internal  service desk project but not to the external service desk

The approach we choose was to have 3 different synchronization users.  These are functional accounts which define the connection that create the comment

• SyncJSD (which is the proxy user)
• SyncCon1
• SyncCon2

The incoming sync processor of the internal connections has following logic to impersonate the comment

The incoming sync processor of the connections contains the following statement

(in the second connection, you would use SyncCon2 ...)

And in the outgoing sync processor, you exclude the comments which are exchanged over the connection as follows

(Obviously, you change the name to SyncCon2 for the second connection )

Why would this work?

Whenever a comment is made on the internal service desk project, it is either created by a user, the SyncJSD user (when it comes from the external connection), the SyncCon1 or the SyncCon2 user (when it comes from the dev projects). The statement !comment.author.username.contains("SyncCon") will filter out all comments that are created in the other dev project, but all other comments will pass through

Whenever a comment is created by the SyncJSD user (ie the customer comment), the comment.auther.username will be 'SyncJSD', and included in the sync message from the internal service desk to both development projects, as it passes the condition.

Ok - the first hurdle met - what's next

• Comments from the dev project on the internal  service desk must be restricted, while the comments  from the internal service desk on the dev project must be open

The way to restrict the comment is explained in 'How to manage comment visibility'.  By setting the comment.rolelevel (check the comment object to the appropriate role, comments will be restricted.  The challenge here is to apply this change only on the internal service desk project and not on the dev project.

The additional complexity is that there are multiple internal service desk projects (kept this for last).  We decided to use the category to indicate the nature of the project.  You could also use other ways of finding out what the type of project it is, but this approach allows us to demonstrate how one can work around a gap in the exalate product. Currently, there is no category in the project object.  As we don't have the time for the exalate team to update the product, we can apply the following workaround

Conclusions

Combining the flexibility of Exalate with the capabilities of Jira, advanced synchronization use cases can be created.  

PS. I had to use images to illustrate the code - the code snippets can be found on our documentation site - Comment visibility - an advanced issue sync case

PPS. If you would like to see this in action, let us know- just book a demo