Last modified: 2011-03-13 18:06:05 UTC
Per the page linked to above, it would be incredibly useful to have a user group for editing protected pages, primarily for bots, but could also be used instead of temporary sysophood, or in the case of the election, for election officials to access the protected pages. This group would have no privileges other than editing semi- and fully-protected pages.
Note that at present, the full-protection permission is set to 'protect', so anyone who can edit fully-protected pages must have the right to protect and unprotect pages. This strikes me as a lousy default, but anyway, that's what we have. To allow what you request, you'd have to ask that the following lines be added to LocalSettings.php: $wgRestrictionTypes = array( '', 'autoconfirmed', 'editprotected' ); $wgGroupPermissions['sysop']['editprotected'] = true; $wgGroupPermissions['editprotected']['editprotected'] = true; $wgGroupPermissions['bureaucrat']['userrights'] = true; $wgAddGroups['bureaucrat'] = array( 'editprotected' ); $wgRemoveGroups['bureaucrat'] = array( 'editprotected' ); and that UPDATE page_restrictions SET pr_type = 'editprotected' WHERE pr_type = 'sysop'; be run on the database. This should all be feasible at this point, and should work, but this will be the first time changes to either $wgRestrictionTypes or $wgAdd/RemoveGroups will be used anywhere on Wikimedia sites, so don't be surprised if shell users decide that they'd prefer to avoid this for fear of breaking the site. If you'd be okay with users being able to protect/unprotect pages it would a be a lot easier, and probably would happen faster. :)
No, bureaucrat should not have the userrights permissions - this would not work on wikimedia. What I am asking is the group is created (with the top three lines) and stewards put the bots/users into the group. That would be more restrictive, and people on wikipedia would not want bureaucrats to have more power (people already claim they have too much power). There are enough stewards, and it only takes a few seconds to do. ~~~~
Well, then it's just $wgRestrictionTypes that needs testing, and that's been around for quite a while.
Ok, this should be done reasonably quickly then - how often do the devs check these pages? ~~~~
Probably it'll be done within a month or two. Updating config files is boring work, and we're talking about a very few people who are mostly volunteers. Which is why we really need some kind of usergroup and namespace managers within the software, so this can be shoved off onto stewards at least if not bureaucrats.
That's my next project then. Move user groups to a wiki-based page. Of course you still have to edit the files to give people the "editgroups" permission, but I guess that doesn't really matter. I finally found something not too hard that would be incredibly useful :-).
I don't think that users should be added into this - sysops aren't supposed to edit fully protected pages as it is. Bots, on the other hand might be useful.
Yeah, it is intended primarily for bots, such as those updating the main page and related things that are protected not so they arent edited, but to stop vandalism. It would also help with another current bot that adds protection tags to pages, which it cant do on fully protected pages.
Yes, adding the notice could be useful, but is there anything else? I can't imagine there being a lot of fully protected pages without tags - and then again, they aren't added sometimes with good reason.
(In reply to comment #8) > Yeah, it is intended primarily for bots, such as those updating the main page > and related things that are protected not so they arent edited, but to stop > vandalism. It would also help with another current bot that adds protection > tags to pages, which it cant do on fully protected pages. Let's not use *that* as an example, it's being disputed on whether or not such a bot is a good idea. But your point still stands that this would be useful for bots, but then we could just set it so that the "bot" group had edit-protected permission... that's a lot different than creating a whole new group.
Bug 10974 is related, rather more general. I also point to http://lists.wikimedia.org/pipermail/wikitech-l/2007-August/032961.html and following posts.
Yes it is, that is a much better solution. :)
(In reply to comment #4) > Ok, this should be done reasonably quickly then - how often do the devs check > these pages? ~~~~ They don't "check these pages". We watch a feed and/or are on a mailing list. :-)
http://en.wikipedia.org/wiki/WP:PEREN#Hierarchical_structures Sorry, but what makes this different from the various other multi-tiered administrative proposals that have been suggested? Why not simply assign sysop rights to a bot and make the botmaster responsible for ensuring the bot only did what it was allowed to do?
(In reply to comment #14) > http://en.wikipedia.org/wiki/WP:PEREN#Hierarchical_structures > Sorry, but what makes this different from the various other multi-tiered > administrative proposals that have been suggested? Why not simply assign sysop > rights to a bot and make the botmaster responsible for ensuring the bot only > did what it was allowed to do? Well, technically, this fix wouldn't just be for Wikimedia... it's a valid point, the ability *should* exist. But you are right, it would be a lot easier to just give the bot sysop status (bot first, then sysop).
For Wikimedia projects, I simply don't see a real need for another group. Protected pages are protected so they don't get edited.
(In reply to comment #16) > For Wikimedia projects, I simply don't see a real need for another group. > Protected pages are protected so they don't get edited. > a) MediaWiki isn't forWikimedia projects only b) The group doesn't have to be used on WMF wikis (however, I already had requests for that on WMF wikis)
(In reply to comment #17) > (In reply to comment #16) > > For Wikimedia projects, I simply don't see a real need for another group. > > Protected pages are protected so they don't get edited. > > > a) MediaWiki isn't forWikimedia projects only > b) The group doesn't have to be used on WMF wikis (however, I already had > requests for that on WMF wikis) I feel the same way, but this is the bug for enwiki, perhaps this discussion should take place off-wiki, or if they are commenting on the technical ability, on the more general bug that you linked.
(In reply to comment #17) > (In reply to comment #16) > > For Wikimedia projects, I simply don't see a real need for another group. > > Protected pages are protected so they don't get edited. > > > > a) MediaWiki isn't forWikimedia projects only > b) The group doesn't have to be used on WMF wikis (however, I already had > requests for that on WMF wikis) > a) I know it isn't. See my comments on the other bug (10974) b) That's good :)
Protected pages are not just used for pages that shouldnt be edited - what about the main page elements? Having one featured article 24/7/365 wouldnt be fun, same as in the news. Also, full sysop rights should not be used, because people don't trust botops, especially if they do not have sysop powers themselves. The community has rejected adminbots time and time again, at least on enwiki. This is a reasonably simple thing to implement, requiring three lines to be changed, and makes no difference unless a particular wiki chooses to use it.
Also, this is a request to be implemented on Wikimedia wikis, not in the general config.
Main Page editing requires more trust - about as much trust as being a normal admin.
That is true in some respects, but that was one example. Also, simply editing is the least damaging of any admin action - you can do near-irreversable damage with any other admin tool, however edits are extremely easy to undo.
Ability to edit MediaWiki: space could result in very bad damage. Would this edit protection right extend to that?
Please discuss this on-wiki and reopen if agreement is reached that this is desired, since it seems unclear that this is the case.
(In reply to comment #25) > Please discuss this on-wiki and reopen if agreement is reached that this is > desired, since it seems unclear that this is the case. Agreed, I was just commenting this on IRC actually. :) A bug that someone wants to be enabled on a certain wiki needs community discussion first. The technical ability request still stands though, as illustrated by Danny_B's bug.
(In reply to comment #24) > Ability to edit MediaWiki: space could result in very bad damage. Would this > edit protection right extend to that? Not unless specifically requested.
The ability of non-Wikimedia projects isn't much an issue here, as non-Wikimedia projects can already create groups assignable in special:userrights (In reply to comment #17) > (In reply to comment #16) > > For Wikimedia projects, I simply don't see a real need for another group. > > Protected pages are protected so they don't get edited. > > > > a) MediaWiki isn't forWikimedia projects only > b) The group doesn't have to be used on WMF wikis (however, I already had > requests for that on WMF wikis) > In fact, you could make a library of predefined usergroups the MediaWiki enduser could copy-and-paste. Perhaps it would be more reasonable to make a category on mediawiki.org to develop those, however?