Last modified: 2011-05-15 09:55:54 UTC
I note with pleasure that the long-standing category redirect problem is to be solved (bug 3311). But this may be exploited by miscreants, since category redirects are likely not to be picked up on watchlists, but will affect article pages. Projects should therefore be able to configure a namespace (such as Category:) so that creating or changing redirects in that namespace requires a higher level of privilege (admins only or whatever) than other edits.
Please close this if such functionality already exists; but if it doesn't, then it probably ought to be introduced at least when the category redirection goes live.
Since a redirect is just a peiece of article text it would be hard to add permissions to it and i don't think that its goes with our openess policies
>Output of MWBOT Bot
><mwbot> Wikis are designed for openness, to be readable and editable by all. If you want a forum, a blog, a web authoring toolkit or corporate content management system, perhaps >don't use wiki software. There is a nice overview of free tools available at <http://www.opensourcecms.com/> including the possibility to try each system. For ways to restrict access >in MediaWiki, see !access.
This is actually *pro*-openness, since it would enable most edits in the namespace to still be permitted, while otherwise it might prove necessary to protect the whole namespace to close the vulnerability to redirect vandalism.
When a category redirect was changed, the redirect target won't be changed automatically. So don't be worried. This just like when a template changed its category, the categories of articles which transcluded the template won't be changed automatically. People need to refresh those articles or wait for system refreshing.
(In reply to comment #2)
> This is actually *pro*-openness, since it would enable most edits in the
> namespace to still be permitted, while otherwise it might prove necessary to
> protect the whole namespace to close the vulnerability to redirect vandalism.
Stop exaggerating. Anytime you restrict an action to a subset of a group, it's being more restrictive, not open.
I can't see any huge purpose in this, nor do we have the right code in place to allow only editing certain text for certain groups (related bugs on this?)
We do have the $wgProtectedNamespaces right, but I don't see a point. Most vandalism reversion is done to quickly for watchlists to be of use, most is reverted by bots and semi-automated programs. I really dobut the need to make a shell change for a piddly little possibility. If someone wants to troll the web looking for evidence the vandals have discovered this change, go ahead. Otherwise, suggestion WONTFIX.
Should've WONTFIX'd this 2 years ago.