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.
There are 2 instances and 4 projects at play
The comment related requirements are
There are thus 3 types of comments
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)
To meet the requirements
The approach we choose was to have 3 different synchronization users. These are functional accounts which define the connection that create the comment
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 )
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.
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
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
francis
Atlassian expert
Exalate
Belgium
42 accepted answers
0 comments