Page MenuHomePhabricator

Make workflows aware of page_id
Closed, ResolvedPublic

Description

I guess we want something similar: if a new board is created on a page that used to exist, old topics don't come back.

T90973: T9. When deleting board or topic, contributions should move from Contributions to DeletedContributions & T90969: T4. Deleting board does not delete the topics or make them inaccessible make sure topics in a deleted board show up (or don't) in the correct places.
However, what happens when a new board is later started on that same page?

Currently, that would (likely - haven't tested) result in those topics to start re-appearing, because that page is no longer deleted.


I was wondering about how to handle restores when a new board has already been created.

Current (non-Flow) behavior seems rather wonky (probably because this never or rarely ever happens):

I created a page & deleted it.

  • archive has an entry for this page
  • page no longer has an entry

Create the page, again.

  • archive has entry got deleted version
  • page has entry for new version

Then restored the old version that was deleted.

  • archive no longer has an entry
  • page still has only 1, the new board (not the one we restored)

Result: restore didn't overwrite page & now it's gone.


workflow_page_id is (well, should be, there's a bug) already storing the page id. We can use it to distinguish between different "versions" of the page.
If a new board is created, it'll get a new page table row, with a new page_id.

  • Fix the bug where workflow_page_id isn't properly populated
  • When a page/board is restored, make sure workflow_page_id is updated to new page_id (via hook?)
  • Make Workflow pageId aware (right now, workflows are loaded based on namespace & dbkey)
  • Fix these deletion thingies to be pageId aware (2 bits of ->getArticleID() !== 0 in code)

Related Objects

Event Timeline

matthiasmullie raised the priority of this task from to Needs Triage.
matthiasmullie updated the task description. (Show Details)
matthiasmullie subscribed.

After we've done this, we should update BoardMover.php, which currently works around the problem of having workflow_page_id = 0 data: https://gerrit.wikimedia.org/r/#/c/201596/3/includes/BoardMover.php

Erik already put up a patch to fix existing workflow_page_id === 0: https://gerrit.wikimedia.org/r/#/c/203962

After making sure workflow_page_id is always filled with the correct page id, we should update that script to LoggedUpdateMaintenance & include it in FlowHooks::getSchemaUpdates() & run it in production.

I also noticed that I'm missing some pages on my local machine. I guess with $wgFlowOccupyNamespaces, it can fail to create an entry in pages table? Not sure, but should investigate: if the pages don't exist, the page_id won't be fixed. In that case, we probably have to create the page?

Change 204735 had a related patch set uploaded (by Matthias Mullie):
Set workflow_page_id when creating a workflow

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

Change 205613 had a related patch set uploaded (by Matthias Mullie):
Fix workflow_page_id when board is restored

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

Change 205614 had a related patch set uploaded (by Matthias Mullie):
Fix checks to see if board/workflow has been deleted

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

Change 204735 merged by jenkins-bot:
Set workflow_page_id when creating a workflow

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

Change 205613 merged by jenkins-bot:
Fix workflow_page_id when board is restored

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

Change 205614 merged by jenkins-bot:
Fix checks to see if board/workflow has been deleted

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

Every restored page and re-created page will have unique id.

When a page is deleted and then restored - the restored page gets a new page id.
When a page with the same title is created - the page will have a unique id.