Sat, Feb 16
To answer my own question, the rule is here: https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/3a406ba1c1976de4e57563cadb3b0fe07c284507/print.less
Thu, Feb 14
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.
Tue, Feb 12
@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
Sun, Feb 10
Fri, Feb 8
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.
Wed, Feb 6
Tue, Feb 5
I had a minor heart attack ;) *jk*
To confirm: is the cu_changes table 12TB for enwiki?
Mon, Feb 4
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.
Sun, Feb 3
I managed to fix the ruwiktionary one using my global sysop rights.
Sat, Feb 2
Fri, Feb 1
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.
Thu, Jan 31
Wed, Jan 30
Mon, Jan 28
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.
Sat, Jan 26
Fri, Jan 25
Happy to be of service!
Thu, Jan 24
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?
Wed, Jan 23
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.
Tue, Jan 22
Jan 19 2019
I would expand it as:
Jan 17 2019
Confirming that this works properly on Wikidata now.
Marking UBN as this has made it impossible for me to use Wikidata for this purpose and no workaround exists either.
Jan 15 2019
Sadly, the example I had kept on fawiki is no more; I was forced to delete the target and proceed with the move, because of a user complaint. :(
I think this should be UBN, per Collaboration/Team/Processes#Definition of Unbreak Now (which specifies that "Any fatal" is UBN). I had marked T213819 as UBN, for that reason.
The move I reported in T213819 is also non-urgent, so I will leave it as is for now, in case any developer needs to try it again.
Per @Volker_E I also want to suggest that we change the blue link color in Vector to Accent50 (#36c) so it matches that in Minerva.
@Volker_E yes, and the delta E I reported there is compared to the blue link color of Vector. That said, it might be a good idea to update the blue link color there too, for more uniformity.
Jan 14 2019
Jan 10 2019
Jan 8 2019
@Daimona I wonder if you could make this happen. I pushed it forward a bunch, but was not skilled enough to get it to the finish line (and also, had difficulty attracting reviews).
Upon page save, it takes 2-3 minutes before servers give up and return an error message. If I were to make an uneducated guess, I would also think of an intermediary such as HHVM.
Jan 4 2019
Thanks for working on this. I found that 420 message hilarious! I resisted making a 420 pun, so instead, I offer you this meme to thank you for all the hard work :)
Jan 2 2019
Thanks Bartosz. I agree that a rewrite will be necessary down the road, but for now, your proposed approach might be a good starting point.
Dec 30 2018
Dec 27 2018
Yes, let's start with Minerva, and then move onto Vector. Current colors in Minerva are already slightly more distinguishable than Vector.
Dec 26 2018
It was the side effect of another Gadget which was trying to call a function that does not exist in jQuery anymore. Fixed with this change on wiki.
Dec 25 2018
Dec 18 2018
Dec 17 2018
Jdlrobson edited projects, added MinervaNeue; removed MobileFrontend, Reading Epics (Wikidata Description Editing).
I can confirm that this occurs with fawiki mobile version on an iPhone. It also happens when I go to https://fa.m.wikipedia.org/wiki/%D8%B3%DB%8C%D8%A8 using Firefox on Mac or Chrome on Windows (so it is not an OS issue, or a mobile versus non-mobile device issue).
Dec 16 2018
Essentially, the ideal way for writing complex patterns while using ccnorm is something like this:
No. I mean if the word 'معین' is a word you intend to look for new_wikitext, then you should not do it as ccnorm(new_wikitext) rlike 'معین' but you should do it as ccnorm(new_wikitext rlike ccnorm('معین').
Step 1: Distinct UAs used by an IP
Identify a user-ip combination that has many user-agent values associated with it
Regarding the two you want removed: I don't think it matters. If you always compare ccnorm(this) like ccnorm(that), the characters will be replaced similarly on both sides of the equation and things will work even if you were replacing ع with E, for instance. Removing them, however, will break AbuseFilters that depend on them in English Wikipedia and similar wikis.