Make it possible to filter events by a given list of event types

[johannaengland]

Closes #699.

[github-actions]

Test results

       7 files     511 suites   20m 1s ⏱️
   412 tests    411 ✔️ 1 💤 0 ❌
2 884 runs  2 877 ✔️ 7 💤 0 ❌

Results for commit bee6399.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.47%. Comparing base (8a3e712) to head (bee6399).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #701      +/-   ##
==========================================
+ Coverage   79.43%   79.47%   +0.03%     
==========================================
  Files          73       73              
  Lines        3608     3615       +7     
==========================================
+ Hits         2866     2873       +7     
  Misses        742      742              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[johannaengland]

After a discussion with @hmpf and @stveit we've come to the conclusion that the user should be forbidden from posting a filter as such:

filter: {"event_types": []}

since that would lead to no events ever being sent as notifications, since every event has an event type.

This should be explicitly documented, both as a test as well in the API documentation.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[lunkwill42]

I guess the big question is whether this will be impacted by the conclusions of #700 - as having an incident filter that includes event attributes is kind of useless and confusing when in the main filter editing form: The incidents list page. Filtering on event attributes here would have no discernible effect on the incidents list.

During notification processing is the only time the make sense, really...

[lunkwill42]

I guess the big question is whether this will be impacted by the conclusions of #700 - as

I might go as far as claiming this PR should be labelled as blocked until we have made this design decision...

[hmpf]

This will be merged after towncrier so add a changelog fragment in the correct place.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[hmpf]

This is as it stands not backwards compatible. I will continue this work in a new branch, reusing the commits.

[hmpf]

Replaced by #813