Author: matthew.britton
Description:
To prevent screw-ups such as this one: http://en.wikipedia.org/w/index.php?title=Special:Log&page=Christianity
Version: unspecified
Severity: enhancement
• bzimport | |
Jan 16 2008, 4:50 AM |
F4630: 12650.patch | |
Nov 21 2014, 10:02 PM |
Author: matthew.britton
Description:
To prevent screw-ups such as this one: http://en.wikipedia.org/w/index.php?title=Special:Log&page=Christianity
Version: unspecified
Severity: enhancement
lunasantin wrote:
Not quite duplicates, but I think Bug 10079 might handle this problem more completely. Aside from protection expiry removing old move-protection, it can also remove old semi-protection (suppose a contentious page has long been under semi, to deal with vandalism, and is temporarily given fullprot, to stop an edit war; should the vandals be let back in, when protection expires?).
flyguy649 wrote:
This would also be useful for pages that are permanently move protected, like WP:ANI, that require short-term semi-protection because of IP vandalism.
random832 wrote:
Is it possible to fully protect with an expiration and have it expire to semi-protection?
(re: expiring from one level to a lower level of protection) Not at this time, though that might indeed be handy.
Created attachment 5210
Patch
Adds an expiry input for each protection type, as noted, the database already supports this. $mRestrictionsExpiry in Title.php and $mExpiry in ProtectionForm are now arrays with the action as keys. If any extension uses these it could potentially break it.
The only outstanding problem is cascading protection. If one protection expires before the other, the page will be left with partial cascading protection (move-only cascading protection). I can think of a few possible solutions for this, not sure which is most desirable:
attachment 12650.patch ignored as obsolete
Created attachment 5211
cleanup/docs
Same as previous patch, some code cleanup and docs in protect.js. Everything in previous comment still applies.
Attached:
If you made only the 'edit' restriction level row have pr_cascade = 1, I would still cascade to pages that use it without any new iterations.
Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can more so should deal with any other issues.
(In reply to comment #9)
Should be fixed in r40601 if auto-reviewing is on. Use of rev_timestamp can
more so should deal with any other issues.
Bah, wrong bug :)