Description

A new feature has been developed which allows filtering the event types among those that have or do not have associated behavior groups with them.

Event types which do not have any associated behavior groups are considered "muted" event types. For this parameter only, event types associated with a default behavior group are also considered "muted" (Slack thread for context).

Endpoint under test

GET /api/notifications/v1.0/notifications/eventTypes?excludeMutedTypes=true

Tests to perform

Default behavior

The default behavior is considered to be the one that has the excludeMutedTypes query parameter as false, or when that query parameter is not specified. This test is probably performed elsewhere.

Exclude muted event types

In this case, the excludeMutedTypes query parameter must be sent with the true value, and a behavior group must be associated with that event type. For that:

1. Create a new event type.
2. Send a request to GET /api/notifications/v1.0/notifications/eventTypes and check that is listed there.
3. Send a request to GET /api/notifications/v1.0/notifications/eventTypes?excludeMutedTypes=true and check that the event type is not present.
4. Send a request to POST /internal/behaviorGroups/default and create a new default behavior group.
5. Send a request to PUT /behaviorGroups/default/{behaviorGroupId}/eventType/{eventTypeId} and link the behavior group to the freshly created event type.
6. Send a request to GET /api/notifications/v1.0/notifications/eventTypes?excludeMutedTypes=true and check that the event type is not present.
7. Send a request to POST /api/notifications/v1.0/notifications/behaviorGroups and create a new behavior group linked to the freshly created event type.
8. Send a request to GET /api/notifications/v1.0/notifications/eventTypes?excludeMutedTypes=true and check that the event type now shows up.