Author: rotemliss
Description:
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).
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T10575 Cascading Page Protection (tracking) | |||
| Open | None | T24521 Cascade-protecting files should protect the file, not the description page | |||
| Declined | None | T10658 Allow cascading protections for non-full protection |
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.
ayg wrote:
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.
robchur wrote:
(In reply to comment #3)
The beauty of full protection is that the edit right coincides with the protect
right.
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.
I was about to make the same point as VoA. I'm going to WONTFIX this - cascading protection on semi-protected pages should never be allowed, because it allows a semi-cascade-protected page to be used to protect arbitrary pages on the wiki. I've made that change server-side (previously javascript was used to stop it) in r25715.
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.