Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Comment visibility - an advanced issue sync case

 

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)

2019-09-21_08-37-54.png

 

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

 

2019-09-21_08-40-28.png

(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

 

2019-09-21_08-41-59.png

(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

2019-09-21_08-43-07.png

 

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

 

 

0 comments

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Marketplace Apps & Integrations

5 mobile apps for Jira Cloud to boost productivity

  It’s very important to have access to the workflow process from anywhere. Especially if you manage the work of others. There is no difference whether you’re out of office, or drive a ca...

226 views 2 5
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you