Markdown summary table

[Neuro-HSOC]

Description

Added support for using markdown format for aggregation summary tables. I introduced the config option summary_table_type with the options ascii and markdown to control the behavior. Within the code I fall back to the default of ascii, if the type is not specified. Therefore there are no breaking changes.

Checklist

• I have reviewed the contributing guidelines.
• I have included unit tests for my changes or additions.
• I have successfully run make test-docker with my changes.
• I have updated the documentation.
• I have updated the changelog.

Questions or Comments

Honestly, I'm not sure how a unit test for a different aggregation table formatting had to look like. Never done one before. I have tested the code by deploying it to my local ElastAlert instance and then raising alerts to my TheHive instance, which supports markdown for the alert styling and the alerts are properly formatted in there.

If you have any advise how to approach such a unit test, I'm happy to try to come up with something. 😄

[jertel]

This looks useful! I see a few formating typos in the docs, should be formatting. Thanks for fixing that preview/suffix bug - I guess no one uses that feature, or just chose to put up with the suffix not showing up. As far as unit testing goes, take a look at alerts_test.py. This has several unit tests already and I suspect you can get started by using one of them as a template. You'd need to build out an expected string with your markdown contents, and then compare that to the one returned by the get_aggregation_summary_text() method. See how far you get and someone here should be able to help you if you get stuck.

[Neuro-HSOC]

Fixed the formating vs formatting typos. The suffix/prefix thing might not be used widely, because as far as I can tell it was never part of the documentation. Likely only people who stare at code know it.

Thanks for the unit test pointer. Will look into this over the next days.

[Neuro-HSOC]

Added a unit test for the changes. Based on that I spotted and fixed a small bug in the usage of summary_prefix. If you would set a summary_prefix value, it would have resulted in a header like this:

This is the prefixAggregation resulted in the following data for summary_table_fields ==> ['field', 'abc', 'count']:

+-------------+----------------+-------+
|    field    |      abc       | count |
+=============+================+=======+
| field_value | abc from match | 3     |
+-------------+----------------+-------+
| field_value | cde from match | 2     |
+-------------+----------------+-------+

Now I ensure a newline, if there is a value for summary_prefix set:

This is the prefix
Aggregation resulted in the following data for summary_table_fields ==> ['field', 'abc', 'count']:

It could be a worthwhile discussion though, whether this "Aggregation resulted in..." should probably just become the default prefix value and should be replaced by a custom prefix, if set, instead of having both.

[jertel]

Nice work on the unit tests and fixing the prefix newline issue.