Hi Jonathon Irwin- we understand the question and also why
The reason why exalate is separating out updating the comment and transitioning the issue (currently) is that there is no association between the comment and the transition on the source.
A potential way to solve this is to enhance the method with
issue.setStatus(String targetStatusName, String commentBody)
or
issue.setStatus(String targetStatusName, HubComment comment)
The difficulty is the combination with mergeComments
Comments added in transitions are also part of the replica.comments, so if the setStatus is enhanced with the comment argument, that comment should not be added by the mergeComments.
Alternatively is to emit only one event per sync transaction, but that has a couple of plusses and minusses.
Bottomline in this discussion is that we are in dubio on the right approach.
If setStatus were to be extended to handle a comment, could the mergeComments/Comments source field be modified to include a flag of "Transitional Comment" which mergeComments could ignore (or include by a flag value perhaps?) dependant on if the sync will be utilising transitions?
In any way - it is a product backlog issue now.
Similar to Satisfy comment validator/required field for status sync (Cloud), same functionality but with added usecase/need so that for notification email purposes with built-in Jira Cloud and Jira Server notifications only one notification is sent (for transition with comment) rather than two, one for Transition and another for the comment.
If the notifications should somehow be merged and this sounds more like unintended behaviour let me know. We also use JEMH in one instance and without the comment being part of the transition it also cannot include the comment in the transition email.