Last modified: 2013-07-19 22:20:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15137, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13137 - Bots to edit protected pages
Bots to edit protected pages
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-24 18:30 UTC by とある白い猫
Modified: 2013-07-19 22:20 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description とある白い猫 2008-02-24 18:30:59 UTC
Especially on wikinews where pages get protected after seven days, protected pages that need bot attention are particularly problematic.

Bots only handle non-controversial mindless tasks on pages. To wait for a page to get unprotected just to be able to add an interiwkilink or fix a double redirect does not feel very logical to me.

Furthermore I do not think it is wise to grant bots all adminship tools just so they can edit protected pages.

If a bots make controversial edits on any page (weather it is protected or not) they tend to  get blocked and loose their botflag - so I do not believe abuse is an issue here.

For pages protected from bot edits (I cant think of a single valid case) there may be a 3rd level of protection above current 'full protection'.
Comment 1 Huji 2008-02-24 20:33:29 UTC
I guess we can define a new permission like 'editprotected', which is set to true for sysops. Wikis like wikinews can define a new group of users (like Trusted Bots or something) with that permission on LocalSettings.php and then a Bureaucrat can assign trusted bots to this group, so they can change protected pages.

If there is no objection (and no-one comes up with a good reason for avoiding the above solution) I will create a patch for it in a couple of days.
Comment 2 Huji 2008-02-25 10:37:05 UTC
With r31247 it is now possible to give the 'editprotected' permission to a group of users, without making them sysops. For example, a line can be added to LocalSettings.php like this:

 $wgGroupPermissions['bot'  ]['editprotected']      = true;

to let all accounts with bot flag edit a protected page.
Comment 3 とある白い猫 2008-02-28 14:04:58 UTC
Thanks for the quick fix!
Comment 4 Brian McNeil 2008-02-29 21:32:44 UTC
Can this be applied on en.wikinews? Do we need a vote on it?
Comment 5 Huji 2008-03-01 08:13:00 UTC
I'm afraid the local community should reach agreement about it, and then you should open a new bug here (not under MediaWiki section, but under Wikimedia > Site request section) linking to the page where the agreement has been archived. A developer with shell access will then apply the required changes for that specific wiki.

As the feature requested here is fullfiled, I'm marking it as FIXED again.
Comment 6 Huji 2008-03-02 19:27:54 UTC
With r31462, I undid the changes made to Title.php, because of a security flaw introduced with r31247. I and ialex are working on the correct solution to this bug.
Comment 7 Huji 2008-03-19 11:24:58 UTC
With r32164 I fixed the bug again, taking care of the cascading issues. For the correct usage see comment #2.
Comment 8 Gerrit Notification Bot 2013-07-01 22:02:26 UTC
Change 71536 had a related patch set uploaded by Anomie:
Fix protection rights usage

https://gerrit.wikimedia.org/r/71536
Comment 9 Gerrit Notification Bot 2013-07-04 05:43:19 UTC
Change 71536 merged by jenkins-bot:
Fix protection rights usage

https://gerrit.wikimedia.org/r/71536
Comment 10 とある白い猫 2013-07-19 22:20:16 UTC
So what is the conclusion? Can bots edit protected pages now?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links