Page MenuHomePhabricator

[3] O5. managing Flow boards outside $wgFlowOccupyPages (spike)
Closed, ResolvedPublic


Someone with flow-create-board right can create a new Flow board, and eventually Special:Flowify will replace the PHP variable (T72073)

  • how can someone enumerate all Flow boards on a wiki?
  • can you move a Flow board?
    • will the topics render correctly "from" the new location?
  • can you delete it (T63730)?
  • #REDIRECTs to it should work, they just don't display
  • #REDIRECT from the board won't (?) work unless you change the content model back to wikitext
  • how can an admin undo the change? (Note T73163 and T75490)

Explanation needs to be on-wiki, and linked from API and the Co-op MatchBot's page.

This ticket is a spike, just to answer the questions -- we'll make more tickets out of this for the next sprint.

Event Timeline

Spage raised the priority of this task from to Medium.
Spage updated the task description. (Show Details)
Spage added subscribers: Aklapper, Spage.
Spage renamed this task from managing Flow boards outside wgFlowOccupyPages to managing Flow boards outside $wgFlowOccupyPages.Jan 5 2015, 10:31 PM
Spage updated the task description. (Show Details)
Spage set Security to None.
Spage updated the task description. (Show Details)
DannyH renamed this task from managing Flow boards outside $wgFlowOccupyPages to managing Flow boards outside $wgFlowOccupyPages (Co-op, also FlowEnable).Jan 9 2015, 7:28 PM
DannyH renamed this task from managing Flow boards outside $wgFlowOccupyPages (Co-op, also FlowEnable) to [3] managing Flow boards outside $wgFlowOccupyPages (spike).Jan 9 2015, 7:32 PM
DannyH updated the task description. (Show Details)
DannyH renamed this task from [3] managing Flow boards outside $wgFlowOccupyPages (spike) to [3] O5. managing Flow boards outside $wgFlowOccupyPages (spike).Jan 12 2015, 9:23 PM

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+