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)

I think autopromote should work with anonymous users for things that are relevant to them, for example IPRANGE. Is this syntax wrong or should I file a bug report?

$wgAutoPromote['localnet'] = array(APCOND_IPINRANGE, '172.31.0.0/12');

restrict user registration to a set of IP range

Someone came in #mediawiki and asked to restrict user creation to only a subset of IP ranges.

// Lines to add to LocalSettings.php

# First deny account creation:
$wgGroupPermissions['*']['createaccount'] = false;
# Create a group named 'subscriber' allowed to create account:
$wgGroupPermissions['subscriber']['createaccount'] = true;

# Uses Autopromote ! 
# http://www.mediawiki.org/wiki/Manual_talk:$wgAutopromote
$wgAutopromote = array(
    'subscriber' => array(
        '|', # <-- promote on any condition below
        APCOND_IPINRANGE, '10.0.0.0/24',
        APCOND_IPINRANGE, '10.5.0.0/24',
        APCOND_IPINRANGE, '172.26.33.0/24',
    )
) ;

# Need to be tested of course :)

Antoine "hashar" Musso (talk) 09:08, 27 March 2012 (UTC)

I just fixed an error in it.  Hazard-SJ  ±  01:31, 12 May 2012 (UTC)

Excluding Namespaces from the EditCount?

Is it at all possible to exclude namespaces from the editcount? For example, if one wanted users to become autoconfirmed after 100 edits, would it be possible to set it so that edits to the "User" namespace don't count towards the 100? Hylian King ZW (talk) 21:55, 7 June 2012 (UTC)

Try this ($wgTitle has been deprecated in 1.19 but it should still work):

$wgExtensionFunctions[] = 'efAlwaysAutoconfirmedInUserNamespace';

function efAlwaysAutoconfirmedInUserNamespace() {
    global $wgTitle, $wgAutoConfirmCount;

    if ( $wgTitle->getNamespace() == NS_USER ) {
        $wgAutoConfirmCount = 0;
    }
}

Regards, Tim (SVG) 22:42, 7 June 2012 (UTC)

Great! We'll give this a try if and when we get the chance. Thanks for the help! Hylian King ZW (talk) 23:08, 7 June 2012 (UTC)

My apologies, it seems my request was misunderstood. What we're trying to do is lower our AutoConfirmCount to 100, but we would like to have all 100 of these edits be guaranteed mainspace edits. We're trying to exclude the user namespace edits from counting towards the 100 total required to be autoconfirmed, in order to prevent users from becoming autoconfirmed through nonconstructive userpage edits. Hylian King ZW (talk) 14:02, 21 June 2012 (UTC)

Oh, my fault. Misread it. I'll look for a solution. Tim (SVG) 12:13, 24 June 2012 (UTC)

I attempted to implement this, but had some trouble getting the join conditions in my query right; see the commented-out FIXME code at whenReachedCount ( $user ). If anyone knows how to fix that, feel free to lend a hand. I could just hard-code an SQL query, at I did with the user/user_groups query in configurePFC_Params(), but that wouldn't be very elegant. Leucosticte (talk) 22:26, 13 October 2012 (UTC)

clarification =

As about number of edits in order to be promoted into a group, I hope it doesn't care about edits which are reversed back into original and it counts only useful articles? Please clarify how does it count edits? Farvardyn (talk) 20:37, 14 May 2020 (UTC)

All edits are considered. Even deleted ones. Ammarpad (talk) 11:57, 15 May 2020 (UTC)