Wed, Jun 19
Tue, Jun 18
Sun, Jun 2
May 25 2019
I don't think you should run it everywhere. At least not until we either fully fix the problem, or fix it in a way that these drifts happen rarely (say, once a day, or once a week). Only in that setting it is useful to have this script executed, so we can identify those rare drifts quickly and try to figure how they happened.
I compared the output of the two Quarry queries; there is very little overlap. Some of the overlapping cases (e.g. Category:خطای_CS1:_تاریخ ) are categories that I know are actively changing (I have a bot working on this one, for instance) so if I were to guess I would say that the script fixed these but they drifted again.
I moved T224321 in the hierarchy of tasks so that the current task would be its parent. @Superyetkin that is essentially what you are asking for. @Krinkle I think it would be nice to start over in a clean state; this can help with identifying the root causes of mismatches, whether before or after #3 is refactored.
Sounds fair. Thanks!
May 24 2019
May 21 2019
Please find it here
Apr 28 2019
Apr 21 2019
Apr 12 2019
I think (though I am not sure) that this is happening because deep inside an IndexLayout, there exists a StackLayout which helps showing only one of the tabs at any given time. So when you put an indexLayout inside a StackLayout, you are essentially nesting StackLayouts, and the CSS model for StackLayouts does not support nesting at all.
Apr 11 2019
Apr 6 2019
Got it. I just saw it today so I thought I should make sure it is noted.
It is a minor enhancement request; no big deal if the decision is to decline it.
I came across this when I was trying to report a few issues, and I wanted to know which version of OOUI was in use where I saw those issues.
Apr 5 2019
Apr 4 2019
One at a time! This is something that takes a lot of political will to happen for each skin.
It bothers me a lot, so I'm posting a fix.
Mar 27 2019
Thanks @Schnark that was helpful. I am updating the task accordingly.
Mar 25 2019
Keyword searching is generally very slow and cannot be made efficient. In technical terms, it is not possible to index a database column that contains strings (like the one that stores the check reasons) in such a way that you can efficiently look for a word appearing in the middle of the string.
Mar 24 2019
Mar 22 2019
To fix it, you need to remove two semicolons. I have shown where it is below:
The second part of the task would still apply.
Thanks @Daimona! I am glad my hunch was right.
Mar 21 2019
@Dalba my hunch is that when you blank the page, AbuseFilter will try to work on a massive diff, and that slows thing down to the point of crashing. Smaller changes produce smaller diffs, and let the page go through.
Mar 18 2019
@Aklapper first of all, I don't see any indication on that page's history that you successfully saved an edit. Please try with a dummy edit instead (with null edits, the issue doesn't reproduce itself).
Mar 12 2019
Perhaps the IP class should have a method like rangeToCIDR()
For the record, I have been going around and adding such links whenever I run into a project in Phab that doesn't have a link to the corresponding Diffusion page. At this point, I think the best "solution", so to speak, is to make sure that whenever a new project is created on Phab, a checklist is followed (do we have one?) and linking the project to its Diffusion is an item on the checklist.
Great. That means the view is not to blame.
Mar 10 2019
Mar 8 2019
I am an admin so I did it. Thanks for the guidance!
Mar 6 2019
Guess what, it was a regression that I had introduced in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CheckUser/+/374851/ more than year ago!
I can confirm that ending the username with _ will cause an exception. Looking for the root cause now.
Mar 2 2019
@Zoranzoki21 can you give me a link to that log? I am wondering if adding a <bdi> tag could fix this, and want to experiment on those examples.
Feb 28 2019
Feb 27 2019
Feb 19 2019
Feb 18 2019
Please see my related comment in T147894#4962824 in which I explain why, at least for now, it is best to restrict the functionality to searching either by IP or by UA (so if both are provided, we would return an error and ask the user to remove one). It is possible (though I am not sure how likely) that allowing both the IP and the UA to be specified would translate to the need for a massive index on the database tables that would be unjustifiable given the few use cases for a joint search, so I would rather differ that to a later time in the interest of having the UA search in production in near term.
@jcrespo The index you created in T212092#4934152 is exactly the one proposed in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CheckUser/+/414120/1/cu_changes.sql so I am a bit confused about what exactly you are asking for.
Feb 17 2019
Feb 16 2019
To answer my own question, the rule is here: https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/3a406ba1c1976de4e57563cadb3b0fe07c284507/print.less
Feb 14 2019
I think it is theoretically possible. The same mechanism that StructuredDiscussions uses to inject rows into the watchlist can be also used by AbuseFilter. We would have to figure out how much demand there is for this though. At this point, I categorize it as a "nice to have" feature, hence the Lowest priority.
Feb 12 2019
@jcrespo Given the analysis you already did on T212092#4934152 would you recommend that we go ahead with creating this index? (If I understand your comment there, the index would be beneficial for a search only on agent and timestamp, with no restrictions on IP).
I am going to decline this Task, per the analysis done in T212092
Feb 10 2019
Feb 8 2019
Several people have described this as a config creep, so I am going to mark it as declined. Let's hope we never get to a day when an eliminator tries to block a sysop.
Feb 6 2019
Feb 5 2019
I had a minor heart attack ;) *jk*
To confirm: is the cu_changes table 12TB for enwiki?
Feb 4 2019
Okay, I like that analysis.
@Daimona if we generalize this problem (which I did in the patch and in its commit message), the issue is not just with "disabled" actions, but also with "undefined" actions. Imagine that you expand the set of actions either through changes in AbuseFilter code, or via hooks and through other extensions; afterwards, imagine you remove those actions, or stop using said extensions. This will leave you with some filters that contain actions that do not exist anymore, which means you don't even have access to the appropriate messages, etc. to even show them in a "disabled" fashion on the filter edit form, to allow the users to uncheck the now-nonexistent actions.
Feb 3 2019
I managed to fix the ruwiktionary one using my global sysop rights.
Feb 2 2019
Feb 1 2019
For doing a hash match, you need to store the hashed UA as a new column in the table, correct? There will be some space implications for it (I think CU tables on WMF production servers are in the 20GB range now, and the largest field in them is the UA field). That being said, I am okay with an interim solution that consists of adding a hashed UA field, indexing it, and allowing exact match searches. That will probably be easier to implement, and it will help us demonstrate several use cases of UA lookups, which would hopefully facilitate moving this task and its parent along.
@jcrespo I created this while you aware away. Just making sure this has not gone unnoticed, and also making sure this is what you would want from me to complete DBA review for CheckUser related sign-offs.