Thu, Oct 17
Tue, Oct 15
Fri, Oct 11
FWIW I imagine folks will continue to use mw.user.tokens where possible because it's just plain easier
Wed, Oct 9
Mon, Oct 7
Sat, Oct 5
Borked in Chrome but seems fine on Firefox on my end (OSX desktop)
Mon, Sep 30
@WhitePhosphorus I don't believe logs work on IP ranges
Sat, Sep 28
Is the definition of "recent" currently hardcoded, or an undocumented configuration option...
Sat, Sep 21
Sep 18 2019
Sep 12 2019
Just came upon https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/526828/8/includes/AbuseFilterHooks.php@279 which would have answered it for me if I'd looked earlier, but thanks for the confirmation!
Sep 11 2019
@matmarex: Is it safe to assume "abusefilter-warning" will return a similar pattern?
Aug 31 2019
Jun 26 2019
Jun 20 2019
@Retro I'm not suggesting using such a signature be disallowed, I'm suggesting pinging via signature alone be disallowed
Jun 18 2019
Can you describe the use case for which you'd like to use this?
It'd be helpful for scripts and the like who wish to be able to offer the flaggedrevs options only when appropriate. In my particular case, this came up when trying to hide pending changes dropdowns in Twinkle for enWiki. They can of course be hardcoded, but that's not very portable across wikis.
Jun 17 2019
Just noting that empty wgFlaggedRevsParams are no longer exported as of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/508427 (T219342#5116724)
Jun 5 2019
Seems like T225116?
May 29 2019
May 10 2019
May 9 2019
May 3 2019
@Anomie It's done in parallel, but the issue here arises specifically with undelete, not with delete, even though both are handled in the same way. That's what raised my eyebrows, since I wouldn't expect delete and undelete to behave/react differently.
May 2 2019
Apr 24 2019
Apr 18 2019
Apr 10 2019
@Volker_E I'm not an expert and may be wrong/out of date, but aren't there either accessibility and mobile issues with collapsing? I vaguely recall DJ putting a lot of work in on that front. One issue I can see is that if you do use the form, the page applies the filters, but the box is collapsed upon reloading and there is no indication you are looking at filtered content without checking the url. Assuming people continue to infrequently use the filters it may lead to confusion.
@Jonesey95 I mentioned this in the link in T107069#5095549, but there was a block on pushing the latest version out (see email and T206678) that led to it being deployed Monday instead. This was listed among the many other changes in that version.
Apr 9 2019
@Etonkovidova Did you see this from my original post?
To further clarify, I think that'd be fine if that was the primary point of the page. But this box represents an obscure action that's barely ever used and now its pushing the primary use of the history page to be below the fold.
Apr 8 2019
@Xaosflux Agreed, but wasn't that the prior version (before ooui-ification) rather than an example?
Mar 29 2019
Mar 22 2019
Mar 21 2019
Wouldn't it make sense to fix this first before going down the route of another user preference...?
Mar 20 2019
Mar 16 2019
Mar 7 2019
Feb 21 2019
Feb 18 2019
I think talk namespaces should be directly after the corresponding subject namespace
I alluded to this in my initial comment, but I actually think it's paramount.
@D3r1ck01 Pardon my ignorance, but it's not clear to me from that patch how this will affect items not in that list, e.g. Module, Book, Draft, Education Program, etc. Will it sort everything, or will it sort namespaces 1-14+100+101, THEN sort the rest? I ask because while namespace numbers may not be known to the average user, the order has been standard for a while and is roughly correlated with how useful something is to a user.
Feb 14 2019
Feb 7 2019
Feb 6 2019
Jan 30 2019
Jan 11 2019
@Tchanders No, this is good enough for me! Clearly mentioned at https://www.mediawiki.org/wiki/MediaWiki_1.30/wmf.12#Core_changes even if it didn't last long. Appreciate having the history.
@Tchanders That makes sense, thanks for clarifying. Was this change documented or noticed somewhere? I think it's a good solution, but was a jarring change.
Is this T213544?
I don't think this has been noted explicitly above, but manually deleting the target page (at least for me) let it go ahead just fine earlier today.
Jan 9 2019
Timing-wise, I suspect this is related to T208649, where the oversight block option is hidden in the same way.
Correct me if I'm wrong, but isn't this a duplicate of T209664?
Jan 4 2019
That's fair, though I only suggested the poor name to match, as with other elements. I stumbled upon it while looking at en:MediaWiki:Group-sysop.js, but perhaps it's best to just deal with inconsistencies en masse after everything is converted.
Completion? The other selectors all have 'em. This should be carried over into T117736 but it stands out here as is. It'd be nice for anything wanting to access it to avoid $('input[name=target]'), as id is preferred for user scripts.
Dec 21 2018
Dec 18 2018
FWIW Modern has a related issue, where they wrap underneath but aren't shown
Dec 15 2018
Unlikely, not a good way/place to deal with theme mismatches
Dec 13 2018
Dec 12 2018
Dec 5 2018
It'd be nice, if possible, to pair a solution for this with a fix for T23272 rather than mirror the issue there (i.e., checkboxes prevent display of oversight status to oversighters).
Nov 30 2018
@Daimona Not to further complicate your work on this, but one thing that is nice about the bulk revision delete system on history pages is that, if an item is already hidden and is then attempted to be hidden as part of a bulk revdel action, the page reports the error on that item but makes the change on all the remaining revisions just fine. Would this have a similar behavior? I'm likewise thinking of T144096 and avoiding creating duplicate entries vis a vis T206945 or T206938.
Nov 28 2018
Moreover, it just adds unnecessary complexity. I could understand allowing it in phases for advanced perm holders as 2FA is required for each in turn, but that still seems needlessly complex. Tgr's one-two punch would help with most situations, and at the least wouldn't make anything worse in the compromised 'crat scenario.
Nov 17 2018
Nov 15 2018
@MusikAnimal Do you have dates/counts on those? In August and September I did a whole bunch of month-long queries and did some very long date ranges maybe a dozen times?
Nov 6 2018
@Daimona Correct, although to your last point, after deleting the page oversighting the deleted revision(s), the AF info was visible to a non-sysop.
@Daimona Thanks again for dealing with this. Am I correct that this doesn't apply on edits that have since been deleted? This is probably closer to T44734, but as far as I can tell, if a page is deleted, and if one of its now-deleted edits is then suppressed, if that edit had initially trigged an abusefilter, that entry it still needs manual hiding.
Nov 5 2018
Nov 3 2018
Oct 18 2018
Oct 17 2018
Please pardon me if I'm being naïve, but isn't the underlying issue that the AbuseLog doesn't follow revdel actions? In a perfect world, wouldn't AbuseLog entries/examinations of successful actions respect the revdel/oversight status of that action? This need not wait for that, but am I wrong in thinking that's the ideal long-term solution?