Full protection expiry should not affect semi-protection
OpenPublic

Description

Author: jack

Description:
Sometimes, it is necessary to fully protect a page which is already semi-protected. Often, the reason for the different protections is different (vandalism and edit warring is a common example), and will have different expiry times. However, if I choose to fully protect a page for a short amount of time, any semi-protection that is set to last longer (or indefinitely) will be erased. It would be helpful if full and semi protection could operate independently of one another, so that a week of full protection would not affect a month of semi-protection.


Version: 1.23.0
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz39038.
bzimport created this task.Via LegacyAug 4 2012, 3:29 PM
bzimport added a comment.Via ConduitAug 13 2012, 10:08 PM

davidswikipediaemail wrote:

It would definitely be nice if this could be fixed. I'm not an admin, but I could see where this could be problematic.

Ironholds added a comment.Via ConduitAug 25 2012, 9:28 AM

This would be nice :). Not sure how it'd work (or if it's possible without a lot of effort) but I'm verifying the enhancement.

bzimport added a comment.Via ConduitNov 19 2012, 6:40 PM

cu.faoil.wp wrote:

I would also like to see this implemented (sysop on German language wiki). There are many pages that are prone to vandalism and should be semiprotected by default, so it would be good to be able to specify whether the page should go back to being semiprotected or not when setting it to be fully protected for any amount of time.

Technical13 added a comment.Via ConduitFeb 13 2014, 4:05 AM

Technically, I think to implement this, each protection level would have to be given it's own column in the table with an expiration date and the highest level of non-expired protection would be applied. I'm not sure how hard it would be to implement, but think it is a good idea.

Anomie added a comment.Via ConduitFeb 13 2014, 3:07 PM

(In reply to Technical 13 from comment #4)

Technically, I think to implement this, each protection level would have to
be given it's own column in the table with an expiration date

That's not actually how the existing page_restrictions table is structured.

What would probably have to happen is that they unique index would have to change from (pr_page,pr_type) to (pr_page,pr_type,pr_level). And then various bits of code would need to be adjusted to deal with this.

and the highest level of non-expired protection would be applied.

It's not necessarily possible to decide that one protection level is "higher" than another. For example, you probably know that enwiki created a new "templateeditor" protection level. What if enwiki decided they also wanted a special protection level for policy pages, and created a "policyeditor" protection level.[1] Which would be higher, "templateeditor" or "policyeditor"?

So what would have to happen is that a page with multiple protection levels active at once could be edited only by editors who could edit through each protection level individually.

There does seem to already be some support along these lines in the code, for example Title::getRestrictions() is defined to return an array of restrictions and Title::checkPageRestrictions() checks whether the user is allowed to edit through all of them. But I don't know for sure whether everything everywhere will correctly handle it.

And despite Title handling multiple restriction levels for an action, there's doesn't seem to be support for the different restriction levels expiring at different times (e.g. Title::getRestrictionExpiry() assumes there's only one relevant time). And then there are the UI issues too, with making a sensible protection form dealing with different restriction levels expiring at different times.

[1]: Yes, this example is *incredibly* unlikely. But it illustrates the point.

Add Comment