Manual talk:$wgAutopromote

i can't have this condition working

i create a new group setting its permissions, and now i want a user belong to this group when he reached 10 edit i use autopromote in localsettings but it doesn't work

this is my sintax:

$wgAutopromote = array(

   'Wrikiano' => array( APCOND_EDITCOUNT, 10),
 );     

where i'm wrong?

Is your MediaWiki version new enough? It only works since 1.12.0. --MF-Warburg 10:43, 14 May 2008 (UTC)

help

Why can I not be approved for this "autoconfirmed" group? I have the criteria stated under the usergroup lists, I believe. My edits are to en.wikipedia though is that why? But I have merged global accounts but have not made edits to 4 other wikis. I cannot override an image of others to a better quality. There was one in the Kobe Beef article on en.wiki that has poor exposure and composition. I don't want to create, and don't know if I'm allowed to make a new image name for it. I don't want to change the image name or upload a new version, just modify the one already there for its quality. Even if I had taken an image myself, I do not have permission to upload it? Why? There are a few more where I can be of help. I have the software, and am interested in fixing images on Commons and en.wiki that have borders needing removal, or brightness/contrast, etc problems. TIA! Here's the link to my contributions so far: w:en:Special:Contributions/Catagraph Catagraph 21:05, 19 June 2008 (UTC)

APCOND_ISIP and APCOND_IPINRANGE

The manual should include some example how to define APCOND_ISIP and APCOND_IPINRANGE in config. —85.175.57.112 03:46, 11 March 2009 (UTC)

Bug or Feature? APCOND_EMAILCONFIRMED supersedes/circumvents Special:UserRights

Using this array in MW 1.15.0, I have found that assigning groups with APCOND_EMAILCONFIRMED using $wgAutopromote gives the rights of the group named within $wgAutopromote, but the users are not actually recorded as being members of the group, so they cannot be removed from those groups in Special:Userrights.

For example, I want to automatically grant editing rights to email confirmed users, but be able to revoke them if the user misbehaves.

Using this code:

$wgGroupPermissions['*']['read']    = false;
$wgGroupPermissions['*']['edit']     = false;
$wgGroupPermissions['reader']['read']  = true;
$wgGroupPermissions['editor']['read']   = true;
$wgGroupPermissions['editor']['edit']    = true;
 
$wgAutopromote = array (
        'reader' => APCOND_EMAILCONFIRMED,
        'editor'  => APCOND_EMAILCONFIRMED,
);

does not allow that. That is, I can check and uncheck the "reader" and "editor" boxes all I want on Special:UserRights with no effect whatsoever if a user has a confirmed email address. To work around this, I had to create a new "demoted" group to ungrant the autopromoted rights.

Workaround:

 $wgGroupPermissions['*']['read']    = false;
 $wgGroupPermissions['*']['edit']     = false; 
 $wgGroupPermissions['reader']['read']  = true;
 $wgGroupPermissions['editor']['read']   = true;
 $wgGroupPermissions['editor']['edit']    = true;
 $wgGroupPermissions['demoted']['demoted'] = true; 
 
 $wgAutopromote = array (
        'reader' => APCOND_EMAILCONFIRMED,
        'editor'  => array ('&', 
                      array(APCOND_EMAILCONFIRMED), 
                      array( '!', 
                               array(APCOND_INGROUPS, 'demoted')
                      )
        ),
  );

This allows me to effectively remove a user from the "editor" group just by checking a box to assign them to the new "demoted" group without having to revoke everyone's autoconfirmed "editor" rights and actively assign each approved user to the "editor" group.

--Fungiblename 14:25, 15 July 2009 (UTC)

AutoPromotion and Custom groups

First my settings in LocalSettings:

// GBD
$wgGroupPermissions["GBD"]["createaccount"] = false;
$wgGroupPermissions["GBD"]["read"]          = true;
$wgGroupPermissions["GBD"]["edit"]          = true;
$wgGroupPermissions["GBD"]["createpage"]    = true;
$wgGroupPermissions["GBD"]["createtalk"]    = true;
$wgGroupPermissions["GBD"]["writeapi"]      = false;
$wgGroupPermissions["GBD"]["editsection"]   = true;

// Auto promotion to group
$wgAutopromote = array("GBD" => array("&", array(APCOND_IPINRANGE, "10.20.19.0/24")));

I looks like the promotion works, but the user is NOT really belonging to that group, so the rights i've set don't work, because MediaWiki doesn't recognize that the user belongs to the group GBD.

I mean that the user can see he belongs to the GBD group in his user preferences, but in the Special:UserRights page (logged in as WikiSysop) the Group GBD is not checked.

How can i make it sure that MediaWiki recognize that the user belongs to group GBD after he is autopromoted?

TIA --217.68.49.85 15:26, 9 November 2009 (UTC)

Did you happen to solve this? 16:12, 15 March 2010 (UTC)

What's not possible with $wgAutopromote

Just a note about what is not possible with $wgAutopromote:

1. Altering the rights of anonymous users (i.e. not logged in)

   Only logged-in users can be promoted.

2. Revoking rights from users.

   If a user belongs to a group that has certain rights (e.g. read), then $wgAutopromote cannot be used to revoke these rights.

Scenario where this would've been helpful:
We have a small wiki in our company which is supposed to be only accessible through intranet and only to a closed group of hosts. The web server is already configured to only allow certain hosts/ips. If a remote host is in this list it can access the wiki. Group permissions for * are set so that anonymous users can read all articles of the wiki without being logged in. Only for writing/editing articles, users must log in. Now some people work from home a lot, but for accessing the wiki they must connect via VPN or some other access method. These methods have in common, that the host accessing the wiki is some gateway server which is not on the access list. Thus I'd like to add this gateway to the access list of the apache, but selectively revoke read rights on the wiki. That way people would have to log in for reading if accessing the wiki through a gateway. If accessing the wiki directly from a known host, they can read anonymously. As I mentioned, this is not possible with $wgAutopromote. I used an altered version of Extension:IPexception to solve this.

--ATHeinrich 10:41, 16 February 2011 (UTC)