Page MenuHomePhabricator

Deleting a page should not affect the old protection
Open, MediumPublicFeature

Description

Author: redrocketboy

Description:
When a page is deleted, any previous protection placed on it is also removed. In the case of the Main Page, when it is deleted by rouge admins, the full protection previously applied to it is lost. The protection placed on a page should not be automatically removed when a page is deleted. Thanks.


Version: unspecified
Severity: enhancement

Details

Reference
bz12343

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:56 PM
bzimport set Reference to bz12343.
bzimport added a subscriber: Unknown Object (MLST).

thogol wrote:

Actual case: A very famous TV quiz show had a question about a sort of tomato. dewiki had no article and the following log was the result (nobody really lifted the protection, all admins there tried to protect that page, but failed...):

http://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&page=Andenhorn

That would have not happened if page protection were independent of existence of the article... ;o)

ayg wrote:

(In reply to comment #0)

The protection placed on a page should not be automatically removed when a
page is deleted. Thanks.

Or more precisely, if it was edit-protected, it should be create-protected with the same protection level.

*** Bug 12774 has been marked as a duplicate of this bug. ***

*** Bug 5986 has been marked as a duplicate of this bug. ***

Created attachment 5542
Adds the requried functionality

The patch I've attached here adds the required functionality; however, it is not ready yet, in two ways:

  1. It throws a warning about an index, which I haven't fixed yet.
  2. As soon as this feature is added, I expect people to request for the reverse too: to be able to keep the "create" protection as an "edit" protection on restoring a page. This patch doesn't address that.

attachment 12343.diff ignored as obsolete

  • Bug 23774 has been marked as a duplicate of this bug. ***

Another Condition, about protection on create:

  1. Protect nonexistant page "AAAA" for new an unregistered users.
  2. Now unregistered users aren't able to create page "AAAA" - OK
  3. An autoconfirmed user or sysop creates the page "AAAA".
  4. A sysop deletes page "AAAA".
  5. Now unregistered users are able to create page "AAAA" - BUG!

Example:
http://es.pokemon.wikia.com/index.php?title=Especial%3ARegistro&page=EP670&uselang=en
(protected on November 11, until 25, created by an autoconfirmed user, deleted,
and then unregistered users were able to recreate it)

/me notes that personally I would consider the current behaviour more correct than the proposed behaviour (since re-creating a page is like creating a new page with the same name, not re-creating the "old" page that was deleted), but maybe I'm just weird.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

Comment on attachment 5542
Adds the requried functionality

Patch no longer applies to trunk - automated testing per http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html - marking obsolete.

sumanah wrote:

Huji, I'm sorry, but trunk has changed since you submitted your patch such that it no longer applies. Would you be interested in talking with us about what the desired behavior should be, possibly via a Village Pump or two and the MediaWiki-General channel on freenode, and then revising your patch to include that functionality? Thank you.

I've just moved a non-protected page ontop of the Main Page (in el.wikipedia) which of course was protected. The old Main Page was deleted (as usual) and the resulting Main Page was not protected (a good user noticed that). I guess that the admin who performs such a "delete and move" action will know in most cases that the page is protected. There should be at least a warning that the resulting page but preexisting title will not be protected any more.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM