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.

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.