Add a config variable (called $wgFlowReadOnly or something) that, when enabled, will cause all attempts to edit/create Flow boards/topics/posts to be rejected, regardless of user rights or global user membership.
This is not easily achievable through the normal permissions system, because different wikis assign flow-create-board rights to different groups, and several global groups have this right, but we can use the getUserPermissionsErrors hook in MediaWiki to achieve this.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add $wgFlowReadOnly | mediawiki/extensions/Flow | master | +39 -18 |
Change 415514 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Flow@master] Add $wgFlowReadOnly
It looks bit different from superprotect. If implemented correctly, it will not allow anyone (even staff) to create a flow stuff, while with superprotect, staff were able to inject ability to edit superprotected pages.
Also, there can be a kill switch regardless of this task’s relation with Commons’ stuff. Reopening.
The original task description doesn't follow How to report a bug , in that it doesn't describe a problem or goal but only a specific proposed solution.
If the goal is to make it impossible to add or change content in Flow boards (Topic namespace), a MediaWiki core setting already exists for the purpose, $wgNamespaceProtection. The documentation page currently suggests to set something like $wgNamespaceProtection[2600] = nonexistingpermission to actually protect a namespace from anyone.
Does Flow respect $wgNamespaceProtection? If not, that's definitely a bug worth addressing.
For one thing it's not a bug report. For another, are we really asking experienced developers writing quite clear tasks (to be carried out by developers) to follow the documentation aimed at new/non-technical people?
This doesn't look exactly like superprotect to me as Roan's commit message says:
The only actions that are allowed are read, delete and undelete.
Though I am interested in why the Flow developers are going down the route of freezing all Flow stuff instead of converting it to wikitext. @Catrope?
Edit: I found https://commons.wikimedia.org/wiki/Commons:Village_pump#WMF_response_to_proposal_to_uninstall_Flow and I think it's fine. Flow stuff will be deleted, this setting will prevent new Flow stuff being created (so Flow stuff won't be seen by the community). It's technically a better idea to do this rather than fully disable the extension, because otherwise a lot of stuff is sitting in MediaWiki history (deletion archive, logs, etc.) that MediaWiki no longer knows how to handle and just starts throwing errors - the code explaining to MW how to do that is simply no longer there. Losing history is bad.
I would think ContentHandler wouldn't give it a choice but I might be wrong.
@Alsee: Please do not close software development tasks as invalid because you personally disagree with them or because one Wikimedia community had a consensus on something. Do not change task status, but add a comment suggesting the change and convincing reasons for it. Thanks.
As far as I know, we have already invested time and energy into creating a proper process to remove Flow from a wiki. We did this with the English Wikipedia (cf. T148611: Plan to disable Flow on Enwiki). From my perspective, adding a configuration variable and additional complexity to the Flow extension and then indefinitely continuing to keep Flow installed on some wikis is a bad approach, both socially and technically. It saddles the wiki with technical debt, with no return on investment, and it creates a higher maintenance burden in order to achieve the same functional result as uninstalling the extension altogether. In the process, rather than respecting the community's wishes, you deliberately subvert them and engender ill will.
Nemo is correct that this task is making a very transparent attempt to introduce a clinical solution without explicitly defining the problem. This is a hallmark of cases where the problem has already been solved and that solution is being deliberately ignored.
Change 415514 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Add $wgFlowReadOnly
Okay, I believe this is done. The two Flow pages on Commons have been deleted, and I replaced them with wikitext exports:
https://commons.wikimedia.org/wiki/Commons_talk:Flow
https://commons.wikimedia.org/wiki/Commons_talk:Flow/tests
With this config change deployed, Flow is now completely disabled on Commons. I think we can close this ticket. Thanks.