get custom fields on comment_created/comment_updated event

[Raf Huys]

we have a custom field, needed in a listener function to `comment_created`, `comment_updated` events.

As this field is not included in the mentioned events, what are my options?

1. is it still possible to include it as an extra field?
2. Is it possible to trigger an `issue_updated` event in the `comment_created` listener?  (which includes the fields I need in its body)

I prefer option 2, but on both I'm still a bit in the dark whether either is even possible. 

[Radek Dostál · Accepted solution]

Hi Raf,

I'm quite confused what the relation between the custom field and comments are - what do you want to do with them in detail? And since we're talking about listeners and events - nauseating details are always good.

How do webhooks relate to this, as it is tagged so?

Thanks,

Radek

[Raf Huys]

we have a 3rd party service which we need to call when a comment on Jira gets added/editted/removed. 

So that's easy: we use a Jira Webhook on `comment_created`, `comment_updated` and `comment_deleted` events.

But the body of Jira's webhook request on these event does not contain all of the issue's content, only the relevant part on the comment.

And that is simply not sufficient. In the 3rd party service, we need a field of the issue which is not included by default. In my case, it's a custom field, but I consider that a detail.

So my question is, how do I get that field to the 3rd party service when a comment gets created/editted/removed?

I hope this is more clear?

[Radek Dostál]

Well, one option that comes to mind is the usage of "url variables" - such as ${issue.key}, then you might be able to supply the request with such additional parameters.

If it works with ${issue.key} then chances are it may work with ${issue.My field name} or ${issue.customfield_11111} - but must say, never tried this so it's just an idea I'd try first.

Other than that, as far as I know issue events come in an "IssueEventBundle" (unless Cloud implements it in a different way) - meaning that for example if you modify a field during a workflow transition, it will fire a bundle that will contain 2 events - one for issue update, one for the transition.

That said, a comment edit should fire just that - comment edit. So if the out of box WebHooks don't contain the customfield data - you won't be able to fit it in there and you would have to supply it in another way (e.g. the variables above).

If variables don't cut it then I'm afraid it sounds that you would be needing to write your own listener to construct your own "WebHook" via an HttpPost (and therefore - creating your own json with the comment info, issueKey, customfields, etc.), or maybe there are some plugins out there that can provide this in a quicker way.

I'm pretty much grown in server deployment so can't try to advise better than that, but that's what I'm getting the impression of when I try this on my cloud test instance.

[Raf Huys]

looks good, thanks!