Page MenuHomePhabricator

Allow users to be blocked from editing pages within a specific category
Open, Needs TriagePublic

Description

Sometimes productive users are unproductive in a certain area of a wiki. Rather than entirely block them, the software can allow for users to be blocked from editing pages within a specific category.

Example; User:Giraffe is a highly productive contributors but has an agenda against Climate Change and regularly disrupts pages with Category:Climate change. If they were prevented from editing all pages within this category their future disruption could be prevented and their constructive edits could continue.


Acceptance criteria
  • After T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace:
  • If an admin specifies a page or category to block:
    • Page blocks can only be set for existing pages/categories only, with validation required in the input field.
    • An autosuggest should help the user find the correct page.
    • Pages can be from any namespace
    • If a page or category is moved, the user should still be blocked from editing (e.g. block by page ID, not page name)
  • If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.

Open questions
  • How do we handle categories that may be on the Talk Pages of applicable article pages?
  • How many sub-categories deep should the category blocks apply?
  • Speed performance drag on UX?
  • How to address situations where a user may use a sock to remove a category from a page and therefore change their own block.

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptMar 21 2018, 9:50 PM
TBolliger reopened this task as Open.Jun 11 2018, 9:19 PM

Resurrecting and separating from T2674

Indefinitely de-prioritized from Anti-Harassment work.

Majora added a subscriber: Majora.Nov 10 2018, 7:50 PM

Not to put a damper on this idea but did we all forget about cascading semi-protection? That was removed because it would have allowed non-admins to perform admin actions. Unless we were to restrict adding and removing categories to admins only this would allow anyone to block people under this type of partial block from additional pages. Which is something that should probably be avoided.

I know that this was de-prioritized but I wanted to mention that just in case someone stumbles across this again.

Nick added a subscriber: Nick.Nov 10 2018, 8:01 PM

I think the issue of category blocking allowing non-admins to perform admin level actions has been highlighted sufficiently often now that it'll have killed category blocking for the foreseeable future, so I'll only mention it briefly, and only to say it's going to allow people involved in content disputes to try and game category blocks by moving pages in and out of categories as necessary. It'll clearly encourage socking and block evasion which isn't good for our already overworked checkusers.

What I would like to add, that's perhaps new, is that categories aren't fixed entities, they change and move as pages are created, deleted and moved around, categories can be merged (and deleted). If I was going to block a user from editing pages in that category, it would in part be on the basis of the pages within the category at the precise point in time I click the button. I don't much like the idea of the category contents changing significantly after I've made an admin action.

In the light of the above comments, I think the only way this could move forward would be as a way of adding a batch of page blocks at once. e.g. if I was to partially block User:Example and set the target as Category:Ships built in Millwall I would actually be blocking them from the ten specific pages in that category and the category page. If, e.g., HMS Eclipse (1860) were removed from that category they would still be blocked from editing it, but would not be blocked from editing any pages added to the category after the moment the block was applied (an explicit note to this effect in the UI would be good).

Regarding sub-categories, I'd say at most it should apply two levels below the specified category (but 0 should always be an option). Especially on Commons if you follow a high level down a few levels you can get some odd results (e.g. Sex → Sex in humans → Religion and sex → Chastity → Virgin Mary → Things named after Saint Mary → Buildings named after Saint Mary → Saint Mary churches).

Stryn added a subscriber: Stryn.Jul 6 2019, 8:34 AM

How about this: We can add all those pages to a maintenance category like "Category:Partial block of User:Example from PROJECTNAME". In Commons, for example, it would be "Category:Partial block of User:Example from (Wikimedia) Commons". Then, we can set an edit filter to prevent all users but admins from adding or removing this category from all pages (possible using a simple regex). A better solution would be a built-in feature to prevent all users but admins from adding/removing the category. I really see no other way.