From 4988d72f43aead08046ec6a653a751d59fd27042 Mon Sep 17 00:00:00 2001
From: Aryeh Gregor <simetrical@users.mediawiki.org>
Date: Sun, 13 Jan 2008 21:36:08 +0000
Subject: [PATCH] The 'rollback' permission now only affects whether rollback
 is made available through the interface.  Users without the rollback
 permission can still use it by generating the proper token through a script. 
 This does nothing but allow automated rollback scripts to generate less load
 on both the client and the server, without allowing them to do anything
 extra.  This was inspired by an anti-vandal bot operator on enwiki who showed
 me his server load dropping in half when his bot switched from manual reverts
 to rollback.

---
 RELEASE-NOTES        |  5 +++++
 includes/Article.php | 20 +++++++++++---------
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/RELEASE-NOTES b/RELEASE-NOTES
index 4f3ba94596..0e6a9e47a3 100644
--- a/RELEASE-NOTES
+++ b/RELEASE-NOTES
@@ -35,6 +35,11 @@ it from source control: http://www.mediawiki.org/wiki/Download_from_SVN
 * New permission userrights-interwiki for changing user rights on foreign wikis.
 * $wgImplictGroups for groups that are hidden from Special:Listusers, etc.
 * $wgAutopromote: automatically promote users who match specified criteria
+* The 'rollback' permission now only affects whether rollback is made available
+  through the interface.  Users without the rollback permission can still use
+  it by generating the proper token through, e.g., a script.  This does nothing
+  but allow automated rollback scripts to operate more efficiently, without al-
+  lowing them to do anything extra.
 
 === New features in 1.12 ===
 * (bug 10735) Add a warning for non-descriptive filenames at Special:Upload
diff --git a/includes/Article.php b/includes/Article.php
index 37a836ec21..34ea259ae7 100644
--- a/includes/Article.php
+++ b/includes/Article.php
@@ -2265,9 +2265,13 @@ class Article {
 	}
 
 	/**
-	 * Roll back the most recent consecutive set of edits to a page
-	 * from the same user; fails if there are no eligible edits to
-	 * roll back to, e.g. user is the sole contributor
+	 * Roll back the most recent consecutive set of edits to a page from the
+	 * same user; fails if there are no eligible edits to roll back to, e.g.
+	 * user is the sole contributor.
+	 *
+	 * FIXME: We shouldn't do permissions checking here; that should be done in
+	 * a wrapper so that server-side scripts can use this if they know what
+	 * they're doing.
 	 *
 	 * @param string $fromP - Name of the user whose edits to rollback. 
 	 * @param string $summary - Custom summary. Set to default summary if empty.
@@ -2286,7 +2290,7 @@ class Article {
 
 		# Just in case it's being called from elsewhere		
 
-		if( $wgUser->isAllowed( 'rollback' ) && $this->mTitle->userCan( 'edit' ) ) {
+		if( $this->mTitle->userCan( 'edit' ) ) {
 			if( $wgUser->isBlocked() ) {
 				return self::BLOCKED;
 			}
@@ -2391,10 +2395,8 @@ class Article {
 
 		$details = null;
 
-		# Skip the permissions-checking in doRollback() itself, by checking permissions here.
-
-		$perm_errors = array_merge( $this->mTitle->getUserPermissionsErrors( 'edit', $wgUser ),
-						$this->mTitle->getUserPermissionsErrors( 'rollback', $wgUser ) );
+		# We do permissions checking twice, for some reason . . .
+		$perm_errors = $this->mTitle->getUserPermissionsErrors( 'edit', $wgUser );
 
 		if (count($perm_errors)) {
 			$wgOut->showPermissionsErrorPage( $perm_errors );
@@ -2414,7 +2416,7 @@ class Article {
 				$wgOut->blockedPage();
 				break;
 			case self::PERM_DENIED:
-				$wgOut->permissionRequired( 'rollback' );
+				$wgOut->permissionRequired( 'edit' );
 				break;
 			case self::READONLY:
 				$wgOut->readOnlyPage( $this->getContent() );
-- 
2.20.1