Thank you for this breakdown of your thoughts and suggestions, @Daimona! They all make sense and sound good to me. On the topic of how we handle deleted pages or edits: I think it makes sense to remove deleted content from the Contributions tab, though I could see an organizer wanting to know (in some way) if content created during the event was deleted. Organizers want to know the full story -- both the good stuff that was produced and the problematic stuff (so they can take action, talk to the editors, provide better training in the future, etc). Probably not something we need to support from the MVP, but it could be useful to consider down the road. As for how we handle the association, I think we probably want to soft delete the association, in case the page/revision gets restored.

Thanks, @Daimona, for deleting stuff. I think soft delete is preferable, and we could use the edit_flags as you suggested. I believe it will give us more flexibility and control over what happens. We could even have flags for page moves if we want to know how often this has happened.

Briefly discussed with @cmelo :

• Approach sounds OK (including soft deletion)
• See if we can handle restores with the same domain events
• Consider indexing the "cec_deleted" (name TBD) field because all queries will need to check it
• Treat all deletions as the same (reminder: it's a cross-wiki revision, can't really perform permission checks)
• Store both page ID (for quick lookup) and prefixedtext (for cross-wikiness). Storing page ID only is not scalable because within a batch you could have edits from many wikis

I will update the AC later.

Change #1190777 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Rename PageEventIngress to EventPageEventIngress

https://gerrit.wikimedia.org/r/1190777

Change #1191162 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] EventContribution: handle page moves and page/revision deletes

https://gerrit.wikimedia.org/r/1191162

Change #1190777 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Rename PageEventIngress to EventPageEventIngress

https://gerrit.wikimedia.org/r/1190777

Change #1191162 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] EventContribution: handle page moves and page/revision deletes

https://gerrit.wikimedia.org/r/1191162

Acceptance criteria

• Given an edit is associated with an event
  • If the page is deleted
    • ✅ Then the edit will not be shown in the contributions table
    • ✅ And it will not be included in the summary
    • ✅ And if the page is later restored
      • ✅ Then the edit will be shown again

before deleting page	after deleting page	after restoring page

• If the individual revision is deleted
  • ✅ Then the edit will not be shown in the contributions table
  • ✅ And it will not be included in the summary
  • ✅ And this will be the case regardless of what parts of the revision (text, user, summary) are hidden, and to what degree (deletion, suppression)
  • ✅ And if the revision is later undeleted
    • ✅ Then the edit will be shown again

QA Note - As it is currently working, this will hide the revision data in the collaboration table from Admin as long as any parts of the revision (text, user, summary) are hidden in Special:RevisionDelete, even if Suppress data from administrators as well as others is not checked. Is this to be expected? I would think admin should be able to see this data if the box is not checked, whereas any non Admin could not see this data.

• If the page is moved to a new title
  • ✅ Then the edit will display and link to the new title in the contributions table
  • ✅ And it will be included in the summary
  • ✅ And this will work for any namespace
    • QA Note - this will not work for ANY namespace, because i can't move from Main to File for example. But it will work for any namespace where I can move an article. Which I believe is the intent of this AC, but leaving a note to clarify

before moving page	after moving page	moving to other namespaces

QA note - I want to check expected behavior around edit undo and rollback. If an edit happens, and then the edit is undone, then an associate edit dialog will open, and if you associate the undo with an event then it will display on the table as a separate edit. And if you don't associate it with an edit, then the edit is not deleted from the table, even though the edit has successfully been undone.

Here's an example where i deleted 1026 bytes, then moved the page, then deleted the revision, and it shows a separate edit of adding 1026 bytes.

And here's a gif of making an edit, undoing the edit. When I undo the edit it asks me if I want to associate the undo with an event, and then if I say yes the reverted edit will display, and if I say no then the reverted edit will not display but the original edit that was reverted will still remain on the summary and table.

Also, if I choose "Rollback" instead of "undo" then it will also not delete the revision from the collaborations table

And, all of this may be out of scope, but I was testing it during this ticket, so if it is out of scope but does need additional work, I can make another ticket

In T403200#11329966, @vaughnwalters wrote:

QA Note - As it is currently working, this will hide the revision data in the collaboration table from Admin as long as any parts of the revision (text, user, summary) are hidden in Special:RevisionDelete, even if Suppress data from administrators as well as others is not checked. Is this to be expected? I would think admin should be able to see this data if the box is not checked, whereas any non Admin could not see this data.

That checkbox is for suppression (see https://www.mediawiki.org/wiki/Manual:RevisionDelete), so it should be hidden a fortiori and fall under:

• And this will be the case regardless of what parts of the revision (text, user, summary) are hidden, and to what degree (deletion, suppression)

QA note - I want to check expected behavior around edit undo and rollback. If an edit happens, and then the edit is undone, then an associate edit dialog will open, and if you associate the undo with an event then it will display on the table as a separate edit.

This is expected, an edit and an undo are two separate edits.

And if you don't associate it with an edit, then the edit is not deleted from the table, even though the edit has successfully been undone. **

Maybe worth considering for a future change, but it can get quite messy.

Okay thank you for these explanations @Daimona. Since this is working as expected, I am moving this to product sign off.

Also... slow clap for "a fortiori." TIL.

In T403200#11330362, @vaughnwalters wrote:

Also... slow clap for "a fortiori." TIL.

(LOL sorry, I got used to writing that in maths/logic and it eventually replaced more normal ways for me to express that concept)