Last modified: 2014-05-08 23:16:07 UTC
Somewhere in the implementation of the resolution to bug 15842, 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.
I'd recommend you open a thread on Meta-Wiki to make sure there is no major blockers from the community. At least ask :)
(In reply to comment #1) > I'd recommend you open a thread on Meta-Wiki to make sure there is no major > blockers from the community. At least ask :) Sure, started a thread here: <https://meta.wikimedia.org/wiki/Wikimedia_Forum#Allow_autoconfirmed_users_to_move_files_on_Wikimedia_wikis_by_default>.
The proposal failed to get any support during this consultation: https://meta.wikimedia.org/wiki/Wikimedia_Forum/Archives/2012-07#Allow_autoconfirmed_users_to_move_files_on_Wikimedia_wikis_by_default
(In reply to comment #3) The proposal also didn't get much opposition.
I can't see enough community consensus (shellpolicy).
(In reply to Steinsplitter from comment #5) > I can't see enough community consensus (shellpolicy). What community consensus do you feel is needed? Is moving a file different than moving a page?
(In reply to MZMcBride from comment #6) > (In reply to Steinsplitter from comment #5) > > I can't see enough community consensus (shellpolicy). > > What community consensus do you feel is needed? Is moving a file different > than moving a page? Yes. More abuse potential. On commons and enwikis exist a own user bug. @MZMcBride: Pleas stop editwarring on this bug.
(In reply to MZMcBride from comment #6) >Is moving a file different than moving a page? Yes. File renaming is problematic because it breaks links, image inclusions on external websites and even temporarily on the Wikimedia Server cluster and lots of different people have different options about how a file should be named... ...
(In reply to Steinsplitter from comment #8) > (In reply to MZMcBride from comment #6) >> Is moving a file different than moving a page? > > Yes. File renaming is problematic because it breaks links, image inclusions > on external websites and even temporarily on the Wikimedia Server cluster > and lots of different people have different options about how a file should > be named... > > ... We should have redirects in place if a file is moved, similar to article redirects. Is there a bug documenting the issues you're describing?
