Somewhere in the implementation of the resolution to T17842, @brion decided to limit the (then-new) "movefile" user right to administrators. As I understand it, this was done as the feature was new and untested and there were still possible security concerns or unknown bugs.
Subsequently, in r93871, DefaultSettings.php was changed to give the "movefile" user right to "user" by default in MediaWiki core. This change was marked "scaptrap" and Wikimedia's InitialiseSettings.php was changed accordingly:
# groupOverrides2 @{ 'groupOverrides2' => array( 'default' => array( 'user' => array( 'reupload-shared' => false, 'reupload' => false, 'upload' => false, // https://bugzilla.wikimedia.org/show_bug.cgi?id=12556 'reupload-own' => true, 'move' => false, // http://bugzilla.wikimedia.org/show_bug.cgi?id=12071 'move-subpages' => false, // for now... 'movefile' => false, // r93871 CR ), 'autoconfirmed' => array( 'reupload' => true, 'upload' => true, // https://bugzilla.wikimedia.org/show_bug.cgi?id=12556 'move' => true, 'collectionsaveasuserpage' => true, 'collectionsaveascommunitypage' => true, ),
I don't see any good reason to restrict "movefile" in this way on Wikimedia wikis. Is there any reason to treat "movefile" differently than "move"?
"movefile" ideally should be available by default to autoconfirmed users, in the same way that "move" is. This means updating the above section to look something like this:
'autoconfirmed' => array( 'reupload' => true, 'upload' => true, // https://bugzilla.wikimedia.org/show_bug.cgi?id=12556 'move' => true, 'movefile' => true, 'collectionsaveasuserpage' => true, 'collectionsaveascommunitypage' => true, ),
Individual Wikimedia wikis can request an override to this behavior as necessary and prudent.
See Also: T29132