Mon, Sep 18
@Tgr the problem seems to be related to the fact that we are creating blocks but not specifying a performing user for the block (only specifying the target). CheckUser would want to log that action, but without a performing user it cannot, and the block fails.
@Tgr, in fact, all blocks on that page are failing. As a first step, I am submitting a patch that checks whether those block insertions succeeded or not. What advice do you have about finding out why insert() fails?
I also sometimes get this one in addition to, or instead of the above:
The issue with the above patch is that while it fixes the DB error, it results in the unit test not passing. The reason is that we do not pass the mock user to the PasswordReset::execute function; we pass the username, and on line 144 it tries to get the user from this username, but fails with a "nosuchuser" error.
Sun, Sep 17
Was assigned by accident. Please feel free to take over or just propose a solution.
I was wrong above. And I think I have uncovered a bigger issue.
For reasons mentioned by bd808
No problem. It was just a bit difficult to track all that in Phabricator, so I submitted the task, then found out the reason and then closed it as duplicate. I wish we had a specific tag for this feature in Phab.
Huh. There was one it is just that it has not been run for most other wikis.
MusikAnimal, I think https://gerrit.wikimedia.org/r/#/c/370946/ should have been accompanied by another patch that introduced an update script that would go through the revision table and retrospectively populate ip_changes for past edits. Was it?
Now I understand. Thank you!
@Tgr it would be overriding addDefaultParams but the issue is that overriding it will cause all options (including --help or --conf) to be shown under "Script specific parameters" and will show a blank "Generic maintenance parameters" section.
Sat, Sep 16
The fatal error happens while running WikiPageTest::testCommentMigrationOnDeletion
Fair. I will work on a patch.
I reverted my LocalSettings to a state where no mention of AbuseFilter exists and I still get the above fatal error.
@Anomie can it have to do with the CommentStore?
The issue was with my environment. sudo apt-get install php-intl solved it.
Fri, Sep 15
POOR NAMING CONVENTIONS
EXAMPLE OF TALLY TYPES
To clarify the above discussion, examples of each tally type are shown below.
Thu, Sep 14
Gotcha. And can you please tell me where in Special:Contributions do we have this kind of functionality (i.e. a second user-specific link shown only when user is provided?)
I was thinking this function (and others) seem easily unit testable. There aren't any tests right now, though? I'm going to write some :)
Please join T175920!
So if no user param set then show one link and if the user param is set then show two links?
Yeah, between me, MusikAnimal and the unit test, we all failed to notice that. :(
It turns out it was actually my own doing in c74d13b37a47; dang it!
@Melos where did that line drop from the code base? For regressions like this, it is always best to find out how they occurred, and mention the patch ID in the commit message.
What is the advantage, @Melos? To me they seem pretty equal.
Wed, Sep 13
Yes; I think the order of tasks is wrong here. T174197 should be a blocker for this task, not a parent of it.
I still think the fact that we generate four files each time is redundant. Using one file in json format would be sufficient. It should include the Unicode codepoint and the actual character only. The .txt file is kind of excessive; we can have a maintenance script that would generate something like that for those interested, but it doesn't have to be part of the code base.
Tue, Sep 12
Coming to think of it, one can just use dump.php --vote to get the votes out anonymously, and then use a few simple regular expression manipulations to make it the output in the desired format.
Mon, Sep 11
PS: Running the .sql file on centralauth database fixes the problem. In the case of WMF, is that where the securepoll tables are located (i.e. inside centralauth database)?
Okay fair. I will try to tackle each one by one. I was not sure our unit tests are so configuration-sensitive.
True, but I think AntiSpoof should actually *remove* certain characters, including diacritical characters, the Arabic/Persian vowel characters (example is Arabic kasra, U+0650), and all invisible characters (examples include ZWNJ, ZWJ, etc).
@DannyH in the 10 months that have passed since T147895, I have actually changed my opinion a bit: there are cases where a user-agent is so unique that you would want to search for it everywhere (i.e. with no IP restriction).
Turns out I could do it myself! Done.