Last modified: 2011-03-13 18:05:57 UTC
This is a bit of a branch from (bug 12650), I just thought it didn't fit there enough to be added as a comment. ---- If possible, stacking protection would be nice. For example, if you have a Main Page, which is permanently semi-protected. But say you suddenly get a string of vandals who go vandalizing the pages included into the Main Page. So you want to temporarily cascade protect the Main Page. If you use an expiry on that Cascade Protection, then when that expires it will disappear and there will be no protection on the page. It would be nice to be able to stack them on top of each other, so that you can add cascade protection, or some other level of protection higher than the current level to make protection fallback when one expires. Say a stack like: * Cascade full-protect expiry 1 week * Page full-protect expiry 1 month * Page semi-protect infinite * Inherent no-protect With that stack, the page would be cascade protected for a week, after that it would fallback to being full-protected for another 3 weeks, then when that's all gone it will fall back to a normal semi-protection. This way gives a versatile use of permissions which doesn't restrict how wiki may decide to deal with protection when pages are vandalized. It could be possible in the user interface by stacking permissions on top of each other, and giving a checkbox to override all permissions with the setting, thereby unsetting a stack of permissions and just setting what permissions should be set. A list of the permissions in the stack would also be good, those could contain a checkbox at the end of each row to allow the admin to selectively remove a permissions row from the stack. Whether permissions should be taken from the stack by highest restriction, or by highest in the stack is up for debate, they each have their pros. For example in the stack: * Page no-protect expiry 1 day * Page full-protect infinite * Inherent no-protect If it was decided to use the highest restriction, then this would prevent new admins from accidentally overriding a restrictive permission with a less restrictive permission by keeping the full-protect and ignoring the temporary no-protect. However, if it was decided to use the highest permission in the stack, then this would give the interesting ability to unprotect a page for a temporary period of time, such as a day, after that period of time the page would become protected again. In essence, rather than protection expiry, it would give us the ability to add expiries to non-protection. An example use of this case would be permanent protecting a highly used template, but giving a 1 hour unprotect to allow one user to improve the template and having it automatically default back to being protected after that hour so the admin can leave and not worry about the template being left unprotected for a long period of time, or needing to make some complected change to the code they can't understand.
*** Bug 10079 has been marked as a duplicate of this bug. ***
The suggested enanchement would be very flexible and useful. But it's rather complex, and (I suppose) not easy to code. So it has not been done yet. I suggest another enanchement: it's partial but (I suppose) easer to code (and to use), so I hope this can be done quicker (something is better than nothing) Just change the meaning of the expire date , to the meaning of "the protection will change to... (another user defined protection level)". I make myself understood with an example. An user set edit protection to level= A. And fix a date and hour (let's call "X"). This tell the software * Now "Set edit page protection to level = A. At day X, the protection will vanish". * With the enanchement that I'm suggesting: "edit page protection to level = A. At day X, the protection will become to level = B" This is a lor easier because, as far I can undestand, it only requires: * Chance in the text "Expires" to "After the day ... set protection level to" * Add a second choice box below the expire/change date. * Add a database column with the "next" protection value ("B", in the example above) It is not as flexible as the enanchement suggested by Daniel Friesen, but it would allow to manage some kind of common issues. For example: * An "hot" page which is normally ("permanently") edit = autoconfirmed, and sometime setted to edit = sysop for some weeks * Un-protecting a page for some hours or some days (as above-mentioned in Daniel's post) p.s. If "It should be possible to enter expiry dates for edit and move protection separately" (bug 12650 , https://bugzilla.wikimedia.org/show_bug.cgi?id=12650 ) will be done, the exipire/change date and the suggested "next protection value" ("B") should be separately (for "edit" and for "move" ) user defined. (Practically speaking, the whole page will be divided in two columns).
This is too awkward and complex, the issue should be addressed with bug 12650, by splitting up the "expiry" setting, so for example, pages can stay move protected while semi-protection comes and goes.
