Here's a description of the bot's behavior: https://en.wikipedia.org/wiki/User:HostBot/Co-op#Matching_members_with_mentors

Enumarating all flow boards on a wiki

• The standard way to signal this is via the page_props table. Any flow page should insert to page props so that it can be iterated over.

Moving a flow board:

• Flow currently explicitly disallows moves, with the message 'Moving a discussion board is currently not supported.'. Removing that check things would still fail, flow has other checks to ensure content is displayed on the expected page. This is not particularly hard to fix.
• The main problem with moving a board is that the topics are pre-rendered to html, and that render takes into account the current location. To properly move a board all wikitext content needs to be re-rendered against the new title
• The current html storage mechanism (ExternalStore) for Flow, the same as core revision content, is not compatible with changing content. You can never delete or update anything in ExternalStore, only insert new data.
  • The plan all along has been to deprecate ExternalStore at some point and switch to restbase. Based on my current understanding of restbase architecture we would also have to transition to a single document per topic(rather than a document per post/summary/etc). This is at least two sprints of work from all team members and there will be bugs remaining.
• It is possible we don't want to change history anyways. Going that route implies that every piece of wikitext content within the board should be null-edited to get a new revision rendered against the correct place. This is a plausible solution but I don't like it. Essentially every post would have a revision labeled something like 'Moved post from Talk:Foo to Talk:Bar'
• This has some odd interactions with future plans to allow topics to be on multiple boards, which board is it rendered against?
• We could instead render topics against their page in Topic namespace(actually we currently do, but there is a patch to make them render against the board instead of topic currently in code review).
  • We havn't done this because rendering against Topic:S09u2340jsdfja is unintuitive to users..
  • We could revisit putting topics under Topic:This-is-the-topic-title-47, this will hopefully be easier with $wgFlowOccupyPages removed, but we will need to look back through the code and find all the places that generate a Title directly from a UUID rather than the workflow instance(not that hard, code is centralized)
  • With topics under Topic:Yet-another-topic-title-93 we still need to be able to handle re-rendering content, because upon renaming a topic its old title should become a redirect to the new title and the content should move to the new page within NS_TOPIC.

Can you delete it?

• Delete is performed through an action, and we dont override it. It works as expected

#REDIRECT to it should work

Just a couple small bug fixes to apply here really, View.php should somehow call $this->page->showRedirectedFromHeader(), and the javascript needs to detect that the current title is incorrect(there is a variable, wgSomethingSomething)

#REDIRECT inside board header does nothing

I'm ok with documenting this as unsupported, the page can be deleted and a wikitext redirect put in its place.

How can an admin undo the change?

The easiest way would be for us to implement a revert action ourselves. There doesn't seem to be anything in particular we can hook into mediawiki for this, but i'm not super familiar. Basically its just a button that says 'disable flow' in the page dropdown and only accessible to sysop+