Similar to Satisfy comment validator/required field for status sync (Cloud)(old community), 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.
Answer by Francis Martens (Exalate) on 23 February 2021
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
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.
Comments:
Jonathon Irwin commented on 23 February 2021
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?
Francis Martens (Exalate) commented on 23 February 2021