Page MenuHomePhabricator

Full protection expiry should not affect semi-protection
Open, NormalPublic

Tokens
"Orange Medal" token, awarded by SpeedyGonsales."Cup of Joe" token, awarded by Man77."Like" token, awarded by Abiyoyo."Like" token, awarded by MGChecker."Love" token, awarded by Luke081515.
Assigned To
None
Authored By
bzimport, Aug 4 2012

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

Details

Reference
bz39038

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:57 AM
bzimport set Reference to bz39038.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 4 2012, 3:29 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.

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.

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.

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.

(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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 13 2015, 8:12 PM
Man77 added a subscriber: Man77.Oct 13 2015, 8:57 PM
Izno added a subscriber: Izno.Apr 25 2016, 12:16 PM
Man77 awarded a token.Nov 15 2017, 6:16 PM

I wrote today on meta (https://meta.wikimedia.org/w/index.php?title=User_talk:TBolliger_(WMF)&diff=18279440&oldid=17799915 ) folllowing text, not knowing of this feature request:


̈́Disclaimer: ... in last 10 years I saw a lot of mediawiki tinkering which surely spent a lot of man-hours, really man-years and not so much of improvement to end users, meaning Wikipedia volunteers.

https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking - This is the first really good idea I saw in years, and now I think I have an idea for another one good improvement.

  • Description of problem/current mediawiki behavior: after lock of page expires, page is unlocked, meaning - no protection at all.
  • Description of wanted mediawiki behavior: after lock of page to sysop level (full protection) expires, page should either go to previous level of protection (e.g. semi-protected), if such exists, or it should be possible to set next protection state of page after full protection expires, when locking the page to set period of time.
    • Comments: temporary solution could be using the bot with sysop flag with accompanying tasklist page (list of pages that should be protected at which times).
    • Answer to above comment: that is not good software design. It should be designed better, smarter, in the first place. (Yeah, right. :)

Maybe this idea already is written somewhere, maybe not. I have no clue. But it's written here and now.


Well, I'm glad that this feature request already exist, as that shows that other people also thought about this. I'm not glad about priority of this feature, because, IMO, this needed to be done long before VisualEditor was even first thought of. :)

I copy-pasted this to let everybody know that maybe powers that decide what is important and what isn't ignored this feature request by chance, as there are lot of feature requests already. This is not critical, but implementing this could spare sysops and patrollers some time, and plug one hole in mediawiki by smart design.