### Problem to solve In https://gitlab.com/gitlab-org/gitlab/-/issues/441195+ we analysed the tables owned by gitlab~12052083 mentioned in https://gitlab-com.gitlab.io/gl-infra/platform/stage-groups-index/compliance.html. This was done to determine the next steps changes required to make them Cells complaint. Here is a list of tables and required changes | Table name | Current gitlab_schema | New gitlab_schema | Comments | |------------|-----------------------|-------------------|----------| | [audit_events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/audit_events.yml) | gitlab_main | | Split the table into 4 news tables | ### Proposal Split the audit events table into the following 4 tables: * UserAuditEvent * ProjectAuditEvent * GroupAuditEvent * InstanceScopeAuditEvent ### Proposed Solution #### Migration - Create migration for new tables. - background migration script to efficiently transfer data from the original table to the newly created tables. Given the substantial size of the table, this process will be time-consuming. #### Model Changes - Introduce 4 new models to interact with new tables. - Update model associations to reflect the new structure and create appropriate scopes to facilitate filtering of audit events within `AuditEventFinder` #### Controller Changes - Modify `AuditEventFinder` to interact with new models instead of the previous polymorphic setup. - Ensure the existing filter functionality remains intact to avoid necessitating frontend alterations. #### AuditEventPresenter - Modify the presenter to handle the new structure. #### Auditor - Update the auditor functionality to write audit events into the respective new tables, this can be done using `entity_type`. #### Database - Where should we store these new tables? * In Cells 1.0, the `user_audit_events` and `instance_scope_audit_events` tables will remain in each cell's database. * In Cells 1.5+, we will need to aggregate this information from each cell. There is no globally shared PG database. #### ClickHouse - Temporarily pause the ClickHouse migration process to avoid potential conflicts or data inconsistencies until the table split and associated adjustments are successfully implemented.