Last modified: 2008-09-13 05:35:22 UTC
To prevent screw-ups such as this one: http://en.wikipedia.org/w/index.php?title=Special:Log&page=Christianity
This is possible database-wise, the UI should just have two Expiry input boxes.
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?).
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.
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 [details] 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: 1. Leave as is. 2. Require all the expiration times to be the same when using cascading protection. 3. Add a pr_cascade_expiry field to the page_restrictions table set to the shortest single expiry time, to have cascading protection expire when the first protection level expires. 4. Only apply the cascading protection to the database row where pr_type = 'edit', and have the cascading protection functions loop over $wgRestrictionTypes when applying restrictions.
Created attachment 5211 [details] cleanup/docs Same as previous patch, some code cleanup and docs in protect.js. Everything in previous comment still applies.
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 :)
Done in r40770.
