[09:31:28] Hi! [09:31:29] I'm developing an extension for a private MediaWiki-based site, and I'm facing an issue with the function that performs edits via the extension. [09:31:34] [09:31:40] The problem is that edits made through the extension are not marked as patrolled, even when the user performing the edit has the autopatrol flag (e.g., a user with the sysop right). I've searched extensively but haven't been able to find a solution. [09:31:47] Does anyone know how I should handle this, or can anyone point me to someone who could explain how to resolve it? [09:31:56] Thanks! [13:39:51] Good moring, I just came across a problem today but couldnt figure out what is going on... on my wiki page I have a simple table, like this: https://ibb.co/9kCLnYvy, when I try to print it to printers or pdf, the contents of the table disappears, it looks like this: https://ibb.co/WNkVMjDL . The only difference is that I recently changed to a new [13:39:52] mac, when I try the same thing on my old mac, everything works fine. BTW I am trying to print on Chrome browser. [14:52:36] I have two accounts where one was improperly renamed, unlinking it from the CentralAuth account. I need to rename the other, but I would also like to reattach the one that got unlinked. The user reached out to us to do it as the account that hasn't been renamed is a deadname, so I'd like to fix it properly. [14:52:46] What's the best way to go about that? [14:54:29] is this on a wikimedia wiki, or another project that is running centralauth? [14:55:40] Not a WMF wiki, no. We have three wikis that use the centralauth system for unified logins. [14:57:21] jfolv: make sure it's actually detached from CentralAuth, rename it locally and then run attachAccount.php [14:57:36] Check the rename isn't just stuck though first too [15:01:41] Should I rename to the new (desired) name on the wiki that wasn't updated? Or should I rename back to the old (the one in CentralAuth) name and then do a global rename after attaching? [15:04:21] jfolv: rename to the new [15:05:16] jfolv: does the rename actually show as completed [15:05:22] Or is it failed / stuck? [15:05:59] Cause in nearly a decade, I can only think of a single case like the one you're describing where it actually gets unlinked [15:06:02] There's no global renames in progress for that account. The problem is that someone used a local rename on one of the wikis and it got detached. [15:06:08] Ah [15:06:26] Which, idk how, because it warns you. But that's end users for you. [15:06:47] jfolv: you should probably disable the ability to locally rename accounts [15:07:05] Not a bad idea, actually. [15:07:26] Never trust users with buttons that are dangerous [17:47:12] Why does the authevents log not include the target username? [17:47:46] It would be very useful to quickly see if someone was repeatedly failing at logging into the same account or trying different accounts [17:50:41] #patches-welcome [17:53:34] Reedy: true, that was more of a is this is a bad idea first [17:54:56] there's not some edge case where MW adds "default" fields somewhere along the way, but the context isn't right, so they're not actually being added? [17:57:19] No idea [17:57:22] Could be possible [18:02:59] no, it seems we just don't add them. there are some more logs in the 'authentication' channel and 'session' channel that you can usually use to correlate this [18:03:12] and at WMF we also have 'goodpass' and 'badpass' logs [18:04:15] https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/8d7a81d32bd389fe66f0e6d690732336d79a2cf5/wmf-config/CommonSettings.php#2287 no idea why they're implemented only there [18:05:04] RhinosF1: patches definitely welcome then :P [18:07:39] MatmaRex: does $user->getName() work for badpass? [18:08:57] apparently