Last modified: 2014-07-26 19:13:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T41038, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 39038 - Full protection expiry should not affect semi-protection
Full protection expiry should not affect semi-protection
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
1.23.0
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-04 15:29 UTC by ItsZippy
Modified: 2014-07-26 19:13 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description ItsZippy 2012-08-04 15:29:10 UTC
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.
Comment 1 David1217 2012-08-13 22:08:56 UTC
It would definitely be nice if this could be fixed. I'm not an admin, but I could see where this could be problematic.
Comment 2 Oliver Keyes 2012-08-25 09:28:02 UTC
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.
Comment 3 Cú Faoil 2012-11-19 18:40:14 UTC
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.
Comment 4 Technical 13 2014-02-13 04:05:23 UTC
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.
Comment 5 Brad Jorsch 2014-02-13 15:07:40 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links