Update Jira with comments and occurence count when repeat of md5 is detected

[123dev]

Hi Gerd, This is a future feature / enhancement consideration that could further enrich this great plugin. Consider it at your leisure and don't feel obligated to add.

It would be useful to have a mechanism to log additional comments to Jira ticket when repeat alerts are raised with the matching graylog_md5

Instead of just skipping logging a Jira ticket, if we could add a _Comment _to the ticket (this would require one more setting for the COMMENT_TEMPLATE), we can capture additional relevant information.

Along with this if we could Count the number of repeats (this would require a jira custom field), we gain few additional benefits. Occurrence Count which could play a big role for the prioritization of the Jira Issue And also cap comment logging in case the occurrence count exceeds a predefined threshold, Just in case a flood of alerts bogs down or unnecessarily dumps too many comments into Jira.

Thanks

[magicdude4eva]

This is doable, but just a few considerations:

• Can you explain what you would put into the COMMENT_TEMPLATE?
• We will have to introduce a checkbox ("Log a comment for duplicate tickets") and then also a COMMENT_TEMPLATE
• Since we introduced an optional filter query (jira_md5_filter_query) it is possible that more than one JIRA issue with the same MD5 is returned.
• If the filter query (jira_md5_filter_query) is defined I would only be able to add a comment to a ticket if the query only returns ONE JIRA issue.
• If we introduce a Count field, this can only be incremented if the JIRA issue is in an editable state for that user (i.e. for a closed JIRA issue you can still add comments, but you can not change fields)
• I would only create one comment per day to avoid excessive comments on an issue. At the moment the JIRA API does not support editing of comments (I logged an issue)

I do like your idea and will probably implement something once the JIRA API supports comment editing.

[123dev]

Hi Gerd,

Can you explain what you would put into the COMMENT_TEMPLATE? It would be similar to what you can put in the JIRA message template but a lot less fields.

Here's one example: *Another Alert triggered at:* [ALERT_TRIGGERED_AT]\n*Source:* [LAST_MESSAGE.source]\n\n*ErrorCode:* [LAST_MESSAGE.ErrorCode]\n*date:* [LAST_MESSAGE.date]\n*time:* [LAST_MESSAGE.time]\n\n*correlation_id:* [[LAST_MESSAGE.correlation_id]|http://123hub?cid=[LAST_MESSAGE.correlation_id]] But it could be anything with more or less field entries.

We will have to introduce a checkbox ("Log a comment for duplicate tickets") and then also a COMMENT_TEMPLATE

Or if there is a COMMENT_TEMPLATE value assume checkbox true, otherwise not.

Since we introduced an optional filter query (jira_md5_filter_query) it is possible that more than one JIRA issue with the same MD5 is returned.

Only if you ignore JIRA duplicate filter query(optional) I would suggest you actually apply jira_md5_filter_query when searching for the md5. This way closed tickets (the default example) with matching md5 would not be picked up, and a new ticket would be created instead of comment added to an existing one (closed).

I can see you getting multiple md5 matches if someone changes the value jira_md5_filter_query in such a way that it no longer filters out previously filtered out duplicates.

In which case I agree with the following.

If the filter query (jira_md5_filter_query) is defined I would only be able to add a comment to a ticket if the query only returns ONE JIRA issue.

Re:

If we introduce a Count field, this can only be incremented if the JIRA issue is in an editable state for that user (i.e. for a closed JIRA issue you can still add comments, but you can not change fields)

I was thinking that closed issues would be treated as non existent issues and new ones would be created in default example: AND Status not in (Closed, Done, Resolved) I would apply jira_md5_filter_query before deciding to add a comment.

I would only create one comment per day to avoid excessive comments on an issue. At the moment the JIRA API does not support editing of comments (I logged an issue)

Please make this optional for people like us who don't mind the extra comments :) We rather not miss the extra details at the expense of extra comments in Jira.

I do like your idea and will probably implement something once the JIRA API supports comment editing.

Why would you need to edit the comments? I was thinking along the lines of add a new comment on each occurrence instead of editing the same one.

Thanks for considering the feature :)