Page MenuHomePhabricator

Proposal: Blocks should exist as serialized pages
Open, Needs TriagePublic

Description

Problem
As Blocking becomes more and more complex (partial blocking by page, namespace, upload, topic(?), etc.) blocks are not as simple as "Is this user blocked?". Likewise, as blocks become more complicated the number of changes to that block will increase, making it more difficult to see the changes between a block and revert those changes. There also is no space to talk about the conflicting changes to a block, or come to a consensus on what the changes should be. Lastly, other than watching the Log, there isn't a way to be notified of changes to a block you are concerned with.

Additionally, making any significant improvements to the data stored with a Block currently requires a schema change.

Solution
To increase administrator productivity and make blocking a collaborative activity, blocking should consist of the same tools that users are familiar with on pages which includes:

  • Talk page
  • Revisions
  • Edit Summaries
  • Diffs
  • Reverts
  • Watchlist

In other words, everything is a wiki page, and Blocks should be too.

Implementation
Create a new content handler for a block that extends the existing json handler. A new Block and Block_talk namespace(s) will be created. When a new block is created on Special:Block that block will be inserted into the ipblocks table and the ID will be used as the title similar to Wikibase: Block:B17. The page will contain all of the public (or permissioned) information about the block, going to "Edit" would load an embed version of Special:Block with the fields filled with the data from the block. All of the non-indexed (queryable) fields from ipblocks will be removed (including the ipblocks_restrictions table). Like Wikibase, the revisions will need to show the field and values that have changed, rather than the changes in the serialized JSON. When saving a block, the summary can be auto-generated (like Wikibase) or the user can optionally provide additional details.

Any overlapping functionality that exists in WIkibase, should be moved into libraries to be used by MediaWiki. Ideally, the Block should be serialized the same way that wikibase serializes entities so that wikis that use wikibase can use existing entity tools (like the Query Service) and APIs with Blocks.

Event Timeline

dbarratt created this task.Oct 28 2018, 7:05 PM
Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptOct 28 2018, 7:05 PM

After the lengthy work we've put into partial blocks, I 100% agree that a more straightforward blocking system that could more easily evolve to meet the needs of our evolving community would bring a lot of benefit to both Wikimedians and those who build software for Wikimedians.

That said, the real trick will be prioritizing building this relative to other work. There are local maximums that partial blocks can provide and we will move on next year to the reporting system. It does appear that we will be prioritizing T100070: Allow CheckUsers to set User agent (UA)-based IP Blocks for early 2019, so at that time we should ask ourselves if it is appropriate to tackle this task at that time, or to keep it on the backlog.

TBolliger renamed this task from Blocks should exist as serialized pages to Proposal: Blocks should exist as serialized pages.Jan 30 2019, 9:41 PM
TBolliger removed a project: Anti-Harassment.
Ltrlg added a subscriber: Ltrlg.Feb 8 2019, 10:55 AM
dbarratt updated the task description. (Show Details)Feb 15 2019, 5:57 PM
dbarratt changed the task status from Open to Stalled.Jul 17 2019, 10:00 PM

@dbarratt: As you set the task status to stalled, who exactly / specifically are you waiting for for further input?

dbarratt added a comment.EditedJul 17 2019, 11:13 PM

@dbarratt: As you set the task status to stalled, who exactly / specifically are you waiting for for further input?

From Product Owners / Volunteers who might want to take this project up.

Aklapper changed the task status from Stalled to Open.Jul 18 2019, 12:00 AM

@dbarratt: That's not what stalled is for per definition. Most tasks wait for someone to "pick them up" and (in theory) nothing blocks you or anyone from doing so.

@dbarratt: That's not what stalled is for per definition. Most tasks wait for someone to "pick them up" and (in theory) nothing blocks you or anyone from doing so.

Got it. Thanks for the clarification.