Add Remediation Steps for each event to Alerts page

[rich-graylog]

Relates to Graylog2/support#47

What?

Graylog 6.0 introduced Remediation steps to Event Definitions, but in the frontend this is only displayed in the Security perspective, and not the General perspective. Given that this is an open feature for Event Definitions, it should be displayed in the General perspective as well.

Why?

Open/Enterprise users can define Remediation Steps in Event Definitions, but are not able to view them when an event fires (this is only available for users with a Security license currently)

This will likely need to be an expandable/collapsible section within the details of an alert that has fired, but should work with UI design to come up with a solution for how it should be displayed on the page.

[coffee-squirrel]

Related to our case 486, it seems. I didn't realize this was an Open feature, since it was only mentioned in the Enterprise/Security changelog (and the event definitions documentation).

I'd ask that this be extended to enable including remediation steps in notification templates. Specifically: it'd be nice to have one or more new metadata fields for the remediation steps, with plaintext notifications having the raw markdown and HTML notifications having the HTML representation of the markdown.

[zeeklop]

@kingzacko1 @danotorrey @ryan-carroll-graylog QQ: Looking into this feature, I can think of two ways to get it done.

1. Modify the EP api/events/search and add resolution_steps to the event definitions context object
2. Fetch the event definition details using the event definition ID in the event

IMO the cleaner way would be to add the resolution_steps to the context object sent by the API. We can then follow the same pattern on the view to show the new information.

[ryan-carroll-graylog]

@kingzacko1 @danotorrey @ryan-carroll-graylog QQ: Looking into this feature, I can think of two ways to get it done.

1. Modify the EP api/events/search and add resolution_steps to the event definitions context object
2. Fetch the event definition details using the event definition ID in the event

IMO the cleaner way would be to add the resolution_steps to the context object sent by the API. We can then follow the same pattern on the view to show the new information.

Agree that 1 is the way to go. It looks like the Context object is shared by event definitions and streams (which don't have remediation steps), so we'll probably need to think about the best way to do this. Could add a nullable remediation steps field, or some sort of customizable field like a map.

[ryan-carroll-graylog]

Related to our case 486, it seems. I didn't realize this was an Open feature, since it was only mentioned in the Enterprise/Security changelog (and the event definitions documentation).

I'd ask that this be extended to enable including remediation steps in notification templates. Specifically: it'd be nice to have one or more new metadata fields for the remediation steps, with plaintext notifications having the raw markdown and HTML notifications having the HTML representation of the markdown.

@coffee-squirrel to keep the scope limited I've created a separate issue to track including remediation steps in notifications: https://github.com/Graylog2/graylog2-server/issues/19864