Page MenuHomePhabricator

Semi-protected pages that were fully protected should automatically return to previous state (#7)
Open, Needs TriagePublic


Survey: 2015

Original wish (German):
"Halbgeschützte Seite soll nach kurzem Vollschutz automatisch in vorherigen Zustand [Umfrage 2015]"

Update sites on-wiki:

If not specified otherwise, for details see T143419: Insights/ Voices from the Community for the page protection wish (#7)

  • People who change page protections are usually admins
  • On de-wiki, there are about 100.000 pages with page protection (see T145385)
  • Protections are not necessarily hierarchical, i.e. you can't necessarily say if something was more or less protected than before
  • Right now there is always exactly one type of protection in place
  • The wiki culture is about trusting people first and correcting mistakes if they appear. The fulfilment of this wish should not undermine the trust culture that has pages unprotected by default.
  • There are pages with infinite protection, though. These are mainly pages that are used in school context (e.g. articles about building tools, animals...) or pages about famous people (e.g. Angela Merkel) or controverse topics (e.g. abortion). Thus there is a high likelihood for vandalism.

Current Hypothesis:
For details see also T142372: Solution ideas for wish #7 - page protection switches
This wish is about pages with an infinite protection. If their protection status is changed (e.g. from infinte half-protect to 7h full-protect), the protection status should return to the infinte one instead of dropping completely.

Related tickets:
T41038: Full protection expiry should not affect semi-protection

Scoping by the TCB team:
not done yet

Event Timeline

Lea_WMDE created this task.Aug 5 2016, 2:32 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 5 2016, 2:32 PM
Lea_WMDE updated the task description. (Show Details)Sep 26 2016, 12:36 PM

Since the protection settings on Wikipedia are only visible with the proper rights, here a screenshot of the current interface to provide context:

daniel added a subscriber: daniel.Sep 27 2016, 1:10 PM

Some thoughts from the technical side:

Page protection is stored in the page_restriction table:

CREATE TABLE `page_restrictions` (
  `pr_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `pr_page` int(11) NOT NULL,
  `pr_type` varbinary(60) NOT NULL,
  `pr_level` varbinary(60) NOT NULL,
  `pr_cascade` tinyint(4) NOT NULL,
  `pr_user` int(11) DEFAULT NULL,
  `pr_expiry` varbinary(14) DEFAULT NULL,
  PRIMARY KEY (`pr_id`),
  UNIQUE KEY `pr_pagetype` (`pr_page`,`pr_type`),
  KEY `pr_typelevel` (`pr_type`,`pr_level`),
  KEY `pr_level` (`pr_level`),
  KEY `pr_cascade` (`pr_cascade`)

This means there can be one protection record (row in the page_restriction table) per page per type, so it's already possible to record full protection and semi-protection separately. This means that this wish can probably be implemented without a schema change.

Without having read the relevant code, it seems the different protection types can be managed separately as follows:

  • when checking the protection of a page, collect all (non-expired) protection records. Apply permission checks as appropriate for each protection type. The permission check must succeeded for each type.
  • when updating the protection of a page, only the selected protection type should be overwritten in the table, protection records with other types should stay untouched.
  • the UI for changing page protection should show all current protection records along with their expiry
Samsara added a subscriber: Samsara.Jan 4 2017, 5:11 PM
Izno added a subscriber: Izno.Jan 4 2017, 8:00 PM

I'd like to see an optional set of parameters for protection to solve this. 2 possible workflows:

  1. Allow applying multiple protection types with related expiration - and AND them when checking if someone has edit permission.
  2. Add a "When expires DO" workflow so you can specify what to do when a single protection expires (default being do nothing).

(1) is the most flexible, but (2) has a unique feature that you could set a page to be temporarily LOWER protection, then have it automatically become higher at a later time.

Xaosflux updated the task description. (Show Details)Jan 4 2017, 8:39 PM
Xaosflux updated the task description. (Show Details)
Man77 added a subscriber: Man77.Sep 26 2020, 8:44 AM