Last modified: 2010-09-15 21:32:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14618 - Enable FlaggedRevs custom configuration on en.wikibooks
Enable FlaggedRevs custom configuration on en.wikibooks
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikibooks.org/wiki/Wikibook...
: shell
: 14704 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-22 23:03 UTC by Andrew Whitworth
Modified: 2010-09-15 21:32 UTC (History)
6 users (show)

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


Attachments

Description Andrew Whitworth 2008-06-22 23:03:27 UTC
I would like to request enabling a custom configuration of the FlaggedRevs extension on en.wikibooks. Our desired configuration, along with our show of community support of it's activation, is located here:

http://en.wikibooks.org/wiki/Wikibooks:FlaggedRevs_Extension

Notification of this bug request to the en.wikibooks community, and potentially a show of additional support for it, can be found at:

http://en.wikibooks.org/wiki/Wikibooks:Reading_room/General#FlaggedRevs_Extension_Bugzilla_Request

Thanks,

--Andrew Whitworth (b:en:User:Whiteknight)
Comment 1 Raimond Spekking 2008-07-02 11:31:39 UTC
*** Bug 14704 has been marked as a duplicate of this bug. ***
Comment 2 Aaron Schulz 2008-07-02 11:42:53 UTC
Looks good. But $wgFlagRestrictions seems confused there. Note that it is for rights, not groups.

'review' is the basic right to review anything at all. So having it more restrictive than 'editor' doesn't make much sense. 'review' should be the "lower" right, and the "higher" one should be called something else, probably 'validate' (since there is automatically a group ("reviewer" with 'validate').

Lastly, that "cascade" variable was removed; it is always on, so not need to have it in the config.
Comment 3 darklama 2008-07-02 13:28:51 UTC
(In reply to comment #2)
> Looks good. But $wgFlagRestrictions seems confused there. Note that it is for
> rights, not groups.
> 
> 'review' is the basic right to review anything at all. So having it more
> restrictive than 'editor' doesn't make much sense. 'review' should be the
> "lower" right, and the "higher" one should be called something else, probably
> 'validate' (since there is automatically a group ("reviewer" with 'validate').

So when the conditions in $wgFlaggedRevsAutopromote are met, a person
is promoted to editor which gives them the 'review' right? English Wikibooks basically
wants anyone who meets the conditions in $wgFlaggedRevsAutopromote to be able to
rate a page based on its composition, accuracy and coverage with a rating level
between 1 and 3, while restricting the right to use a level 4 rating to sysops.

So if I understand correctly $wgFlagRestrictions should be set to:

$wgFlagRestrictions = array(
  'composition' => array( 'review' => 3 ),
  'accuracy' => array( 'review' => 3 ),
  'coverage' => array( 'review' => 3 ),
);

and anyone with the validate right will be able to set each flag to 4.

The configuration section of FlaggedRevs.php in svn suggests that
sysops and bureaucrats can't review and validate pages without belonging
to the editor and reviewer groups. If this is the case than sysops and
bureaucrats need to have all the editor and reviewer rights set for them
as well, so that sysops and bureaucrats have the rights to 'review' and
'validate' pages.
Comment 4 Aaron Schulz 2008-07-02 13:51:00 UTC
By default, sysops can grant/revoke 'editor' group rights, and crats can grant/revoke 'reviewer' group rights.
Comment 5 darklama 2008-07-02 15:27:42 UTC
(In reply to comment #4)
> By default, sysops can grant/revoke 'editor' group rights, and crats can
> grant/revoke 'reviewer' group rights.

I'm not talking about the right to grant or revoke these two groups. Rather
that since the proposed settings for $wgFlaggedRestrictions was incorrect
that what we want in order to achieve the results we were after would be
equivalent to sysops and bureaucrats automatically belonging to both groups.

For instance by doing:

$wgGroupPermissions['sysop']['review']          = true;
$wgGroupPermissions['sysop']['autoreview']      = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;
$wgGroupPermissions['sysop']['patrolmarks']     = true;
$wgGroupPermissions['sysop']['autopatrolother'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;
$wgGroupPermissions['sysop']['validate']        = true;

$wgGroupPermissions['bureaucrat']['review']          = true;
$wgGroupPermissions['bureaucrat']['autoreview']      = true;
$wgGroupPermissions['bureaucrat']['autoconfirmed']   = true;
$wgGroupPermissions['bureaucrat']['patrolmarks']     = true;
$wgGroupPermissions['bureaucrat']['autopatrolother'] = true;
$wgGroupPermissions['bureaucrat']['unreviewedpages'] = true;
$wgGroupPermissions['bureaucrat']['validate']        = true;
Comment 6 Aaron Schulz 2008-07-02 23:32:54 UTC
If you want to skip the step of "self-promotion", that config is fine, except for the fact that Sysop has 'validate' for some reason.
Comment 7 darklama 2008-07-02 23:45:28 UTC
(In reply to comment #6)
> If you want to skip the step of "self-promotion", that config is fine, except
> for the fact that Sysop has 'validate' for some reason.

That's because the intention was for sysops to be able to validate pages as
featured by changing the 3 flag levels to 4, not just bureaucrats.
Comment 8 Aaron Schulz 2008-07-02 23:47:07 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > If you want to skip the step of "self-promotion", that config is fine, except
> > for the fact that Sysop has 'validate' for some reason.
> 
> That's because the intention was for sysops to be able to validate pages as
> featured by changing the 3 flag levels to 4, not just bureaucrats.
> 

I see. Are there any bureaucrats that are not sysops btw?
Comment 9 Mike.lifeguard 2008-07-02 23:48:17 UTC
No, there aren't.
Comment 10 Mike.lifeguard 2008-08-06 20:44:43 UTC
Do you need more info for this bug, or is it clear now?
Comment 11 Aaron Schulz 2008-08-13 17:31:45 UTC
Hmm, lots of differences from defaults (which were tweaked for WMF recently). At any rate, looks like we need:


$wgFlaggedRevsNamespaces = array(NS_MAIN, NS_IMAGE, NS_TEMPLATE, 102, 110); // Cookbook, WikiJunior

$wgFlaggedRevTags = array(
  'composition' => 3,
  'accuracy' => 2,
  'coverage' => 2
);
$wgFlagRestrictions = array(
  'composition' => array( 'review' => 3 ),
  'accuracy'    => array( 'review' => 3 ),
  'coverage'    => array( 'review' => 3 ),
);
$wgSimpleFlaggedRevsUI = false;
$wgFlaggedRevTabs = false;
$wgFlaggedRevComments = true;

$wgFlaggedRevsAutopromote = array(
  'days' => 30, # days since registration
  'edits' => 100, # total edit count
  'excludeDeleted' => true, # exclude deleted edits from 'edits' count above?
  'spacing' => 3, # spacing of edit intervals
  'benchmarks' => 15, # how many edit intervals are needed?
  'recentContentEdits' => 10, # $wgContentNamespaces edits in recent changes
  'totalContentEdits' => 50,  # $wgContentNamespaces edits
  'uniqueContentPages' => 10, # $wgContentNamespaces unique pages edited
  'editComments' => 50, # how many edit comments used?
  'email' => true, # user must be emailconfirmed?
  'userpage' => true, # user must have a userpage?
  'userpageBytes' => 1 # if userpage is needed, what is the min size?
  'uniqueIPAddress' => true, # If $wgPutIPinRC is true, users sharing IPs won't be promoted
  'neverBlocked' => true, # Can users that were blocked be promoted?
  'noSorbsMatches' => false, # If $wgSorbsUrl is set, do not promote users that match
);

$wgGroupPermissions['sysop']['review']          = true;
$wgGroupPermissions['sysop']['autoreview']      = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;
$wgGroupPermissions['sysop']['patrolmarks']     = true;
$wgGroupPermissions['sysop']['autopatrolother'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;
$wgGroupPermissions['sysop']['validate']        = true;
Comment 12 Cary Bass 2008-11-05 17:59:57 UTC
Adding my name to this.  Is there any more holdup on this now that we've got the things in place?

Cary
Comment 13 Rob Halsell 2008-11-14 23:12:44 UTC
FlaggedRevs is now enabled on this project.. closing bug.
Comment 14 Aaron Schulz 2010-09-11 19:49:08 UTC
DB query indicates that some pages are using a custom "precedence/selection" setting for the stable version. This feature should be removed. What is it used for currently?
Comment 15 Aaron Schulz 2010-09-15 21:32:58 UTC
(In reply to comment #14)
> DB query indicates that some pages are using a custom "precedence/selection"
> setting for the stable version. This feature should be removed. What is it used
> for currently?

This is the "Stable version selection precedence" option at special:stabilization for pages.

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


Navigation
Links