Allow filtering of streamed audit events
# Problem Users want to receive specific types of audit events in a streaming manner, but since the stream currently returns all events at once, they have to manually filter out the ones that they don't care about. ## Use Case Examples 1. An organization wishes to send all changes related to group-level MR settings to a system for compliance teams to review but doesn't want them to have to look through all of the different events GitLab records. 1. An organization has two different compliance teams, one which monitors who has access to projects and groups, while the other monitors when projects and groups are deleted. Each group has a different external system they use for recording events. Each group only wishes to see the results that are relevant for them and ignore the rest. # Proposal Introduce APIs to filter the results from streaming audit events. These APIs should be done on a per-endpoint basis, to allow for users to customize it for their use case. Allow the user to select which individual events they want to and do not want to receive at the endpoint that they configure. ## MVC For an MVC, this can be done with GraphQL APIs only and omit a GUI screen. This will allow users to get started and builds on top of our GraphQL-only MVC. Introduce APIs to: - List which events are being streamed to the given endpoint - Cause the endpoint to receive all events - Cause the endpoint to receive no events - Cause the endpoint to receive a specific event - Cause the endpoint to no longer receive a specific event ## Future Iterations In subsequent iterations, this capability will have a screen-based UI that a user can use either along with or instead of the API. Those screens should present the same options as above that the API allows. The UI should also allow filtering events in "groups". That is, events of similar types will be combined together so that users can select a set of events rather than one individual event at a time. An example might be "all project-level MR settings" events as a group. Consider this when designing & implementing. A concept illustration for what this might look like is in [this comment](https://gitlab.com/groups/gitlab-org/-/epics/5925#note_581931330). # Licensing ~"GitLab Ultimate" <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
epic