Volunteer Developer, Beginner Security Engineer.
Alternative Account: @SnowDragon
Thanks a lot !
@Rxy are you looking for test data to use while testing, or just an environment to test it on?
For the former, could we manufacture test data. We already have makeTestEdits.php, we could modify it to use random IP/XFF info. For the latter, we can set up a cloud VPS project with multiple wikis instead of relying on beta cluster. It wouldn't be identical, but we could install enough extensions to make it close enough for testing purposes. Would that meet your needs?
Krenair is correct, and I also think that enabling CU on Beta is not a great strategy.
There may be other reasons that I am not aware of, but the main reason behind this request is perhaps to have a test platform with some diverse CU data. That, indeed, signifies how poorly the CU code is right now, in terms of unit tests, as well as the need for a maintenance-type script that could populate fake CU data on a test wiki. Instead of working around these, I think the right solution is to augment the code and make it easier for you and future developers to have the ability to test CU without needing to collect real-world data on a test wiki.
Yeah but to SSH in you would've had to agree to the labs TOU at some point. I don't think that's needed to hold on-wiki flags.
if needed, I can disabled for using checkuser for non specified users.
Your pointed tasks are both is targeted to antispam. but this task is not so. I need a testing for Global CheckUser function before directly deploying to production.
Almost accounts are created by another account. and the global block is enabled an option "Block anonymous users only". It means account user is still can be creating an account. Also another account user is created by non global blocked IP address.
I can not reproduce that.
I guess hideuser / suppress user are should be stored in user table instead of ipblocks table. and they should be handled by User class. not a Block class.
When an account created at somewhere, CentralAuth does add Job to each wikis defined by $wgCentralAuthAutoCreateWikis. if lagged or JobQueue is busy, I guess may account creation is lagged .
Thanks for advice!.
What do you mean with a "single DB cluster"? I don't know much about the cu_changes table, but as far as I know there is one table per wiki (where it is enabled)
If you just need to add a new field to the current table (on each wiki) you'd need to follow the schema change procedure: https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change
Please allow enough time for the schema change to happen (it can take up to months, depending on how big the table is).
This error is occurred due to pycodestyle 2.4.0 added checking for W605.
Thanks for comments all. but this ticket is not proposal for drop the local "steward" group or discussing how handles "remotely userrights change" system.
If you hope these,please file a new ticket.
I suppose the reason that the userrights right can't also go is local custom groups that don't appear on meta?
I removed URL-upload_(testing) group by removing membership from Bastique
Caban group member gug_user 99 is not exist.
@Reedy Thanks for deploy.
New version. Tested in all cases (anonymous/sysop/oversight user vs visible/deleted/oversighted element), and it seems to work.
This is an updated version which should also solve the discrepancy between deleted and suppressed revs. An important note: I haven't tested it! It should be tested in several cases: visible, deleted or suppressed revision, and basic/sysop/oversighter user.
This is my patch, where the examine part is copied from Rxy's patch (and slightly beautified). Also, please note that this vulnerability also affects Special:AbuseFilter/test (fixed by the change in AbuseFilterChangesList)
(file was updated, it wouldn't have passed CI, and that's the last thing we need).
Also, we should probably make a better distinction between deleted and suppressed stuff, but it's fine to merge this for the moment.
Thanks for explain that!
I wrote the patch for this.