Confluence has been updated to version 6.15.9

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)

Comment
Sync
Behavior
Map (From/To)



External
Service
Desk
Internal
Service
Desk
Dev Project ADev Project B
External Service Desk
RestrictedOpenOpen
Internal Service DeskOpen
OpenOpen
Dev Project ANot allowedRestricted
Not Allowed
Dev Project BNot AllowedRestrictedNot Allowed



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 which created 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

// set the author of the twin comment to SyncCon1

issue.comments     = commentHelper.mergeComments(issue, replica, {
							comment ->
                            comment.executor = nodeHelper.getUserByUsername("SyncCon1")
                            comment
		})

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

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

replica.comments = issue.comments.findAll { comment ->
                        comment.author.username == "SyncCon1" ||
						!comment.author.username.contains("SyncCon") 
                     }

(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


// fetch the project  category using the Jira API
import com.atlassian.jira.component.ComponentAccessor
def projectManager = ComponentAccessor.projectManager
def jProject = projectManager.getProjectByCurrentKey(issue.projectKey)
def jCategory = jProject.projectCategoryObject


// If the category is 'Service Desk', set the role level to 'Team', else null


issue.comments     = commentHelper.mergeComments(issue, replica, {
							comment ->
							comment.roleLevel = (jCategory.name == "Service Desk") ? "Team" : null
                            comment.executor = nodeHelper.getUserByUsername("SyncCon1")
                            comment
		})



Conclusions


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