Last modified: 2014-11-17 09:21:11 UTC
To make the cascading protections more usable, it makes sense to protect for
sysops only if one of the "parent" pages is protected for sysops (or even
better, if the protection level for cascading protections is set in the
protection form). Otherwise, autoconfirmed protection should be used (we could
make the algorithm smarter than that and use other groups, but I don't see the
point to do that).
As it stands, the software has no concept of "semi-protection" and "full
protection". Implementing this would involve teaching the sofware about which
protection is "higher" than the other.
I don't think defining a hierarchy of levels is necessary; requiring that the
user be able to pass _all_ the various cascaded protections probably would do
the expected thing.
The main difficulty is perhaps that our current model is to give a list of
possible permission keys and require that the user satisfy _at least one_ of them.
I'm not really sure how best to integrate these two models but I'm sure some
smart fella can figure it out. :)
The beauty of full protection is that the edit right coincides with the protect
right. Even if semipro did cascade as semi-pro elsewhere, the autoconfirmed
right does not align with the protect right :S.
We shouldn't allow cascading autoconfirmed, see bug 8796. It should be possible for different
protection levels to cascade, perhaps, but only if it's specifically enabled for them.
(In reply to comment #3)
> The beauty of full protection is that the edit right coincides with the protect
Only by default. Most things should never work on the basis that two rights will
be held equally.
My issue is with users being able to "protect" other pages with this, which I
really don't like.
Is it possible to actually cause the page included in the cascading-protected page to be editable by autoconfirmed users as well instead of sysops only? Sorry if this was brought up already, but I can't resist talking about it.
Please open a separate bug for this distinct request.