After someone associates an edit with an event, the following information could change:
- The page might be moved to a new title
- The page might be deleted
- The individual revision might be (partially) deleted/suppressed
Because the DB table that tracks collaborative contribution is derived from `page` and `revision`, it needs to react to these changes to the source data, presumably via the relevant domain events (if possible) or hooks.
For page moves, we should aim to 1) display the current (most recent) title in the table view, and 2) not double count the same page in the summary view if it was moved. On the technical side, we would store the page ID. This alone would have us covered in case of page moves, but not for showing the page title in links; that would require querying the `page` table on multiple wikis, which isn't ideal. So we could keep storing both the page ID and page prefixedtext, and update the latter when needed. (And remember to add an index on wiki+page ID for these updates)
For deletions, we need to avoid info leaks. For example, we could exclude all edits to pages that have been subsequently deleted, and also exclude all revision that have been revdelled (regardless of what parts of the revision have been deleted, like username or revision content). Another question is whether we would hard-delete the association, or soft-delete it and bring it back if the edit is undeleted. On the technical side, this would be either a hard DELETE, or a boolean flag (could be a new column, but maybe we can reuse the edit_flags colmun?). Also worth noting: if we exclude revisions regardless of what part was deleted, we don't need to fully replicate rev_deleted.
===Acceptance criteria===
TBD