Indeed

I ask because I'm not seeing that:

@Urbanecm You're welcome!

One could adjust the :after although I'm not certain what folks would consider appropriate there, given the sizes are fairly equivalent. Further left (65%?) and a bit down?

Resolved, the subsequent issue filed in T246931

Not that I'm opposed, but would having this imply a mirrored unblock capability? What about protection and deletion?

T160233#5907969 explicitly states that needs more buy-in, so this definitely shouldn't wait for that.

Fair enough, opened T245990.

@Umherirrender, et al.: this is much appreciated, but as-yet incomplete. AFAICT, the dropdown for AbuseFilter entries still only draws from MediaWiki:Revdelete-reason-dropdown and doesn't account for the new page. I can open a new task if you like, but since AF logs can only be suppressed, not revision-deleted, that means the new page can't really be used.

Thanks — I had thought you meant someone else was involved, so that's good to know. And yes, I'd agree that T160233#5568022 still seems to be the operating state.

In T160233#5905997, @Demian wrote:

And we have discussed in great detail that it does not add any extra powers or abuse potential.

3.5 years later, I think the case for this is (obviously) stronger. Compared to the levels that IE 6 and 7 were used when they were dropped in mid-December last year (T232563), these versions of Safari are even less used.

Yes, and I think it would be helpful for anyone in the future to know how many revisions were involved in that deletion.

Anywhere where revision deletion or suppression could be used, it'd be useful, in particular I'm thinking of Special:Log. It's useful on Special:Nuke as well. I'm not sure it's needed on Special:UserRights, although it would make removal of redundant rights after getting sysop easier, albeit rare.

Maintainers of chosen just yesterday marked it as deprecated and unmaintained: https://github.com/harvesthq/chosen/commit/91041bc9dd6867f9a1668050a1b092d92027f13b

I wouldn't say this is quite a duplicate — T88250 dealt specifically with OOUI, this is about replacing one external with another. As noted above but even more true now, select2 is somewhat more maintained and featureful (cf. https://github.com/harvesthq/chosen/pull/166)

T160233#5568022 and T160233#5568111

T160233 is marked as stalled and is noted as requiring an RfC at minimum, with a chance of not happening at all. I wouldn't think this needs to wait on that unrelated process.

But one of the best revdel-related improvements lately is persistence of revdel status during deletion/undeletion (and choice thereof). I certainly wouldn't want to do away with that, i.e. have all revdel status reset on deletion. Likewise, it's unlikely but if a page with extensive history is deleted, allowing revdel of those deleted revs means that if it is restored, they will still be revdel'd. Unlikely, but far from unheard of, with both revdel and suppression status.

Pretty sure this is invalid, check out https://en.wikipedia.org/wiki/Special:Undelete/Draft:Swarup_Solanki, specifically the move.

You have the Autolink gadget enabled in your preferences, that's the cause of this.

@DannyS712 That sounds like T197501 or T201784

Sorry to bug you again @Krenair but at your leisure, could I bother you for a tidy-up I've caused? There's no security issue thanks to this, but my change meant there's now an omnipresent "false" message that shouldn't be there. If you could do another simple change on those same Twinkle pages (listed here in global search) I'd be quite grateful. See https://github.com/azatoth/twinkle/pull/797 and https://github.com/azatoth/twinkle/pull/798

All clear AFAICT, thanks all for the swift work.

@Anomie I actually meant to update this to something like your comment in T239527#5709615 after playing around with things more recently; there's enough of a difference in how we'd want to treat what could be called a "user" (account, single IP) and what could have edits displayed (that + range) that I think that's the right course.

Alongside wgCurRevisionTimestamp, might as well have wgRevisionTimestamp, to parallel wgCurRevisionId and wgRevisionId.

The parallel to action=unprotect is really Special:Unblock, which likewise doesn't load the existing block reason, as unblocking (and unprotecting) shouldn't want the existing rationale pre-supplied. There is an argument to be made that action=protect should come preloaded an already-existing rationale, much as Special:Block does, but the reality is that, whereas Special:Block is where blocks are modified and is separate from Special:Unblock, unprotect and protect are the same thing.

Noting this here since I don't think protection itself has been mentioned (here or in T233561), but I've now twice run into permissiondenied errors when trying to change an article from pending changes to semiprotection (enwiki, ofc).

Agree with Urbanecm here. On enwiki, AFAICT there's one single page in the whole namespace (two if you count the talk), so I have a hard time imagining there's much content elsewhere. In the end does this task just devolve to allowing a dozen or so people on enwiki to add an {{R from...}} tag or two? I think it's fine to grant to intadmins (and stewards) but it's only going to end up with more content somewhere.

In't this T234170 and T232085?

FWIW I imagine folks will continue to use mw.user.tokens where possible because it's just plain easier

Borked in Chrome but seems fine on Firefox on my end (OSX desktop)

@WhitePhosphorus I don't believe logs work on IP ranges

Is the definition of "recent" currently hardcoded, or an undocumented configuration option...

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!

@matmarex: Is it safe to assume "abusefilter-warning" will return a similar pattern?

@Retro I'm not suggesting using such a signature be disallowed, I'm suggesting pinging via signature alone be disallowed

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.

Just noting that empty wgFlaggedRevsParams are no longer exported as of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/508427 (T219342#5116724)

Seems like T225116?