Fri, Apr 12
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.
Thu, Apr 11
Sat, Apr 6
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.
Fri, Apr 5
Thu, Apr 4
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.
Wed, Mar 27
Thanks @Schnark that was helpful. I am updating the task accordingly.
Mon, Mar 25
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.
Sun, Mar 24
Fri, Mar 22
To fix it, you need to remove a semicolon. 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.
Thu, Mar 21
@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.
Jan 31 2019
Jan 30 2019
Jan 28 2019
On one hand, this is a project management question. Do we want to make an exception (as @Zppix suggested and @Rxy desires), and let this get to the production faster, or do we want to use this bottleneck and require @Rxy to solve this issue (of inability to test CU code easily) once and for all.
Krenair is correct, and I also think that enabling CU on Beta is not a great strategy.
Jan 26 2019
Jan 25 2019
Happy to be of service!
Jan 24 2019
Entering this discussion abruptly, so I'm not sure how useful my comment is, but: please note that unlike edits (which are all in one place), logs are stored in different places, and it is wrong to assume that this field is meant to point to a logging.log_id as, to the extent I understand it, logs that are in other tables can also trigger filters. At least in theory. Unless I am totally misunderstanding the code.
Would you like me to translate the new version?
Jan 23 2019
Could we revert the beta cluster to the versions @Anomie pointed out, test the issue, and then move the beta cluster forward one revision at a time until the issue appears (or disappears)? After all, the beta cluster has the closest setup to the WMF production.
Jan 22 2019
Jan 19 2019
I would expand it as:
Jan 17 2019
Confirming that this works properly on Wikidata now.