Bumping to UBN, since if I'm right this is cause of T228462, that's worth UBN I think.
I believe this might caused T228462. See my comment in linked task for details, due to Security.
Some context here: Firstly, that's about edit limit, not move limit.
Really? I have no problem to move hundreds of files from a category to an other category using Cat-a-lot in a few seconds. But it is a problem to rename about 10 categories in one minute. As I can see, this is affected just by move limit, not by edit limit.
thanks for flagging this @Urbanecm
I'm not sure it's a big problem since the user page will then show "Homepage" as one of the top navigation tabs.
Perhaps we could analyze the EditorJourney data to see if this is a problem among first 24 hour editors.
The alternative seems to be to modify the target for the link to go to Special:Homepage.
@Urbanecm -- are you saying that the module on the homepage should make it more clear what happens when the user clicks "Ask the help desk"? Because once they do click it, the modal that opens explains what will happen.
Stalling, WMF-Legal response might take some time.
Wed, Jul 17
That's in contrary with what @Bstorm said, but fine.
I disagree. Dumps is not the same thing as typical Cloud NFS. It's functionally a distribution channel for materials produced in production. The fact that WMCS maintains it is mostly because it supplies that to Cloud hosts. I was bringing it up to explain what the differences are between that and this request.
We can not mount filesystems from the Cloud Services network realm on hosts in the Production realm.
Can you explain in greater detail what problem you're trying to fix? I suspect that historically any copy (including wget) was limited by NFS performance, which should be considerably improved by hardware and network changes -- and, in any case I wouldn't expect wget to be substantially slower than cp on a given network and server.
Closing - I believe the bug has been fixed. If this is still wrong, please reopen&comment.
This seems like a bad idea. Scratch is writable by all of cloud. I do not want that mounted in production, if that's what we are ultimately talking about.
T194864#4213365 "The limit was supposed to be an upper bound and not affect actual users. Im sorry for the inconvinence and am totally ok with a higher limit (as long as all groups that you can be auto added to have a reasonable rate limit)" (BWolff)
Thank you, @AlexisJazz. Let's wait for a week or so and process this unless someone opposes.
And it should be raised to the point where legitimate users don't run into it. That's not quite about consensus, this is a technical thing. We never voted to have this move rate limit in the first place.
@DannyS712 that's on top of the MediaWiki defaults? MediaWiki default is 8 moves per minute AFAIK, which would seem plausible if the system was counting Arjoopy's moves over 2 minutes.
If Commons has no rate limit for moves it's a bug, because Arjoopy came nowhere near 10500 edits.
Should be fixed.
How possible would it be to have an open system that allows people to create modules and implement them?
Last dry run: P8759
Tue, Jul 16
No problem :) Time to set this public? (I don't have that button for some reason.)
If it's deemed security sensible, we could restrict the calls to relevant IPs.
What IP ranges do you fell comfortable with? Preferably it should be restricted to wikimedia internal network.
Since i did some recent uploads...yes, being able to directly access v2c files will surely be helpful. ideally, one directory per request would be helpful as well.
Marking as blocked on SRE. Having T226937#5330884 resolved is a requirement for Radomlje_-_Nafta_1903_0-0_(2._polčas).webm.
waiting on more files to transcode
Works for me on enwiki beta, thanks @matmarex!
Happy to help!
For the reasons mentioned above, @Base was promoted to a steward on some closed wikis. If this is not wanted, feel free to revert.
I've tried mwscriptwikiset createAndPromote.php closed.dblist --custom-groups=steward --force Base, but that a) yelled that I must pass a password (contrary to the docs, fixed that and uploaded 523694 for in-script fix), because account Base does not exist on (some) closed wikis b) when I ran mwscript createAndPromote.php --wiki=wikimania2005wiki --custom-groups=steward --force "Martin Urbanec" "some random password" to try it first with my own account, it said Cannot create account: The requested username is already taken by a user on another wiki.. It seems it's not possible to create an account on SUL closed wiki with createAndPromote.php.
This will be deployed during Wednesday.
What is the status of this ticket? Is the fix merged and ready for 1.34-14, this week's train? As-is, it seems train can't move beyond cutting the branch.
Mon, Jul 15
I'm sorry, I thought so because said conversation directly followed the report from @Daimona.
Looks like a temporary error to me.
Change 522558 merged by jenkins-bot:
[mediawiki/core@wmf/1.34.0-wmf.13] RedirectSpecialPage: handle interwiki redirects.
Thank you, @Anomie.
@Steinsplitter This task isn't about _deleting_ this group from our wikis. This is just about removing the group from extension.json (=stuff defined there is applied on all wikis that make use of UploadWizard, unless they override it in LocalSettings.php), in favour of redefining this in Wikimedia wikis configuration. The redefining has been already done for commons btw, since the group is now called image-reviewer internally, while it was Image-reviewer previously. There will be no change for Commons, and filter 70 will work just as it works now.
This is not a user right that the extension needs apparently, and the mass-upload permission can simply be assigned to commonswiki image-reviewers via InitialiseSettings.php IMHO.