This is likely a duplicate of T167219.

Same here. I did this: https://meta.wikimedia.org/w/index.php?title=Global_sysops&diff=19079406&oldid=19001329

In T200938#5094768, @Niharika wrote:

@MarcoAurelio @DerHexer @revi @Trijnstel It sounds like there is consensus to show partial block information on the CentralAuth page. We could do this similar to how it is displayed on Special:BlockList (5th column):

Does that sound good to everyone?

I agree with @MarcoAurelio, @DerHexer and @revi.

In T118024#4853254, @greg wrote:

In T118024#4823328, @MarcoAurelio wrote:

Per my amended description above. This needs to be addressed now. I am fed up of having vandalic edits (some of them plain libel, death threats, etc.) misattributed to me because of this.

Unfortunately that's not a good reason for using UBN!, I'm setting this to High instead. I agree that it still needs to be fixed as soon as it can be.

I've activated 2FA on phabricator and I already find that annoying. Let alone when I need to use that for user right changes (T197150) and, even worse, for checkuser actions.

I've activated 2FA on phabricator and I already find that annoying. Let alone when I need to use that for user right changes and, even worse, for checkuser actions (T197158).

@4nn1l2 @Huji @jrbs I've found another scrutineer for you who wants to help: @alanajjar

PS. For me this is visible: https://www.mediawiki.org/wiki/Topic:Ujbpgpbtbszkwgt8

See the two relevant suppressions on 10 September 2018: https://www.mediawiki.org/wiki/Special:Log/suppress/Trijnstel

It's been six days since the rename now, and nothing has happened. Could someone please look at it asap? Tnx. @Tgr @Legoktm @Keegan @Jalexander

Seven years since this bug was first filed, for a loss of CU logs in 2006, and still nothing has been done.

@hoo Can you help with this bug as well?

In T196268#4251948, @Framawiki wrote:

Found https://meta.wikimedia.org/wiki/MediaWiki:Gadget-renameQueueReason.js gadget, that is enabled by default for global renamers and stewards. This script is broken because it can't find the new "reason" input.
I've requested a temporary hotfix on https://meta.wikimedia.org/wiki/Meta:Requests_for_help_from_a_sysop_or_bureaucrat#MediaWiki:Gadget-renameQueueReason.js_needs_hotfix

See also this hold change that implement it in the extension but that still need help: https://gerrit.wikimedia.org/r/#/c/197944/

Suggestion from someone else to add a confirm option, so no one would accidentally click on the vanish button.

In T184344#3907361, @herron wrote:

In T184344#3896337, @Trijnstel wrote:

Btw, messages to the list admins are received by me, so I see no reason to change my email address. I’ll look at changing the bounce settings this evening, but that obviously doesn’t solve this problem.

The DSN explaining why the hotmail address bounced should have been forwarded to you (a list admin) at the time subscription was disabled. If that didn't happen the message containing this information likely bounced as well. Perhaps another list admin has this information?

Btw, messages to the list admins are received by me, so I see no reason to change my email address. I’ll look at changing the bounce settings this evening, but that obviously doesn’t solve this problem.

In T184344#3887190, @herron wrote:

Hi @Trijnstel, it appears that messages from this list to your hotmail account have been bouncing.

Jan 06 01:27:01 2018 (666) global-renamers: trijnstel@redacted.tld current bounce score: 4.0

However, mail volume from this list has not been enough to push your bounce score over the threshold (which would automatically disable membership, send a notification to yourself and send bounce details to the list admins).

As a list admin I'd suggest temporarily using an alternate email address for list administration (since the hotmail account is having a problem) then adjust the bounce threshold to more quickly disable and send details about bouncing email addresses to the list admins. If you choose to go this route please keep in mind that the bounce score is incremented by a maximum of 1 point per day that bounce messages are processed.

In T184408#3882322, @MarcoAurelio wrote:

It serves to help discard false positives when dealing with large number of accounts when doing mass global locks.

In T184344#3881185, @Aklapper wrote:

Duplicate of T127008?

In T181906#3876587, @herron wrote:

Just now I sent 3 testing messages with different subjects and 3 replies (one reply to each subject). The problem is happening for me as well. The reply to subject "testing3" was not delivered by email or archived.

The missing message did reach the lists MTA and the log indicates it was delivered to the mailman command, but there is no trace of the message in the mailman post log. So it seems the issue may lie somewhere in the handoff between MTA and mailman.

@RobH @Dzahn have you encountered similar symptoms before?

In T181906#3832347, @herron wrote:

Hello, I've just adjusted the dmarc_moderation_policy for this list (under privacy options > sender filters) in an attempt to rule out DMARC as the cause of delivery issues from a hotmail address. Could you please check to see if this helps?

If the problem persists I would suggest temporarily enabling list archival for further troubleshooting and testing to see if the problem can be reproduced from a different email provider.

In T181906#3832695, @Natuur12 wrote:

I just send two email to this list. One using my hotmail account and one using my gmail account. Both didn't arrive and both are subscribed to the list. I didn't receive any of the mails.

After this I enabeled the archives and send two more testmessages but the archives are still empty.

I did check my spambox on both occasions.

Did someone find the time to fix this? Platonides maybe? Up til now nothing happened... and I'd say it's pretty urgent.

In T160529#3283666, @NickK wrote:

This happened again today, this time targeting checkuser-l and another user (will not disclose username here but one thing in common is that this user also uses mail on their own server). It is somewhat disturbing to receive spam on a non-public mailing list

Useful suggestion. Thanks.

Would definitely useful, yes. Thanks.

I've checked a few random tickets in permissions-commons and can confirm that it's resolved. Closing this bug report now.

In T150835#2803554, @Johan wrote:

Mails sent to the mailings lists (awaiting moderation); folks have been notified on their talk pages.

Definitely. It would be nice if this could be fixed soon. Thanks.

I've updated this page: https://meta.wikimedia.org/w/index.php?title=Www.wikipedia.org_template&diff=15744971&oldid=15729043 - its documentation says "The generated code draws from the following unprotected pages". One of them is https://meta.wikimedia.org/wiki/Module:Project_portal/wikis. But why doesn't it update this then? https://meta.wikimedia.org/w/index.php?title=Module:Project_portal/wikis&diff=15744965&oldid=15742229

In T137215#2431929, @MZMcBride wrote:

I guess this spelling came from https://meta.wikimedia.org/w/index.php?title=Module:Project_portal/wikis&oldid=15742229; diff: https://meta.wikimedia.org/w/index.php?title=Module:Project_portal/wikis&diff=14404681&oldid=14396741.

This wiki page was imported and the same string now appears at https://phabricator.wikimedia.org/diffusion/WPOR/browse/master/data/site-defs.json;f1cc4d94e7d9609a5e4c4a0064cf55df485e9959$1156 and https://phabricator.wikimedia.org/diffusion/WPOR/browse/master/data/new-site-defs.json;f1cc4d94e7d9609a5e4c4a0064cf55df485e9959$2702.

Changing this string should be trivial.

HELLO? Is anyone working on this? It's pretty annoying that no one seems to care to quickly fix this... I apologize if I'm mistaken, but it certainly looks this way.

@hoo, @tstarling, @Reedy: And it's a year later... Any update here?

In T98625#2270371, @Krenair wrote:

@Trijnstel, @MarcoAurelio: If you guys are happy with the text it'll go into Extension:WikimediaMessages in that commit, and when that change gets deployed we'll be able to use to set up the form.

Some layout changes on small and private wikis? Because another user also reports it about nl.wikisource, see (in Dutch) https://nl.wikisource.org/wiki/Hoofdpagina and https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Graag_hulp_op_wikisource

Good suggestion... But: there are 700-800 projects. If the WMF would register this domain, then they probably should do the same for dewikipedia.org, frwikipedia.org etc. I'm not sure we could ask that from them...

In T111898#2015194, @MarcoAurelio wrote:

[...] and ptvoy change reverted fwiw, but that's another debate [...]

In T12493#1998586, @Luke081515 wrote:

In T12493#1998534, @MGChecker wrote:

(...) and the interface would be much more complex too. (...)

No, you just need a dropdown for the expiry time, and a field for custom time, like at Special:Block. (If you want to set permanent, you can set expiry=never)

In T12493#1998534, @MGChecker wrote:

(...) how is this going to be displayed in the log? (...)

Just like the block log. For example:

20:38, 24 November 2015 Luke081515 (talk | contribs | block) changed group membership for Luke from editor to administrator and editor (temporary) with an expiry time of 2 weeks

That's my proposal.

Any update on this one?

In T69541#1618398, @Billinghurst wrote:

Personally, I don't see this as a bug. I definitely don't see it as problematic and I actually find it useful to check that the process worked.

"and also to get rid of one or two annoying special cases in the code for that particular log" - what do you mean? The fact we have a suppression log is good, imho. I mean, where else should you put suppression actions without having others access to it? Is this only about a suppression where one deletes+suppress a page at the same time?

In T41213#968049, @gerritbot wrote:

Change 184116 had a related patch set uploaded (by Glaisher):
Allow blocking talk page access and send email access optionally

https://gerrit.wikimedia.org/r/184116

Patch-For-Review

See for a related bug report T40297

Any update on this one? What is needed here?

PS. Note also T116414 and T46836 + this was discussed in SF two months ago... (ping @hoo)

In T114873#1708358, @gerritbot wrote:

Change 244140 had a related patch set uploaded (by TTO):
Disable title blacklist on private wikis

https://gerrit.wikimedia.org/r/244140

I don't see the need for this proposed change. It can only confuse people and there is no reason why non-oversighters should see that an oversighter did something. I propose to decline this request.

@csteipp: Any idea when this patch will go live? And could you please 'warn' us on time by sending an email to stewards-l via your wikimedia email address? Thanks! :)

With T95857 being fixed recently, I think that this bug (limiting from a /19 block to a /48) should not be done.

In T106067#1461194, @Krenair wrote:

In T106067#1460810, @MarcoAurelio wrote:

we can think about granting the 'unblock' rights on those wikis to the bureaucrats?

We don't have a separate 'unblock' right... I don't understand why you would want to do that anyway?

In T20660#1521304, @Glaisher wrote:

To be honest, I don't think we need global blocking by global abusefilters at all. Local blocks for global abusefilters is also not allowed per current consensus among the community.

From what I've seen, we are currently doing fine with manual blocks whenever needed by stewards so there is no need for this (at least for now).

In T98625#1530455, @Jalexander wrote:

For the record I'll look into this, likely next week. Our dept is short staff atm (Kalli and I at a child protection conference, Philippe out of the office etc) and so waiting until we come back is likely best.

I have now. 😅 But it looks like it's not working yet.... Nothing in the suppression log entry on that diff (and for that diff) yet...

As an addition, I see I can mark the first page here: https://nl.wikipedia.org/w/index.php?title=Amargosawoestijn&oldid=44538491&diff=prev ("[Als gecontroleerd markeren]" is mentioned next to "Nieuwere bewerking" and below), but I don't see such a link here: https://nl.wikipedia.org/w/index.php?title=Amargosawoestijn&redirect=no (see printscreens)

More examples:

• https://nl.wikipedia.org/w/index.php?title=Amargosawoestijn&redirect=no (originally named "Amargosa Desert")
• https://nl.wikipedia.org/w/index.php?title=Lijst_van_voetbalinterlands_Filipijnen_-_Pakistan&redirect=no

In T62373#1455021, @Krenair wrote:

@Trijnstel, the script has been run on slwiktionary. Please check for logs on https://sl.wiktionary.org/wiki/Special:RevisionDelete?type=revision&ids=89131
If that works we can run it on nlwiki to check the given example, and if that's fine as well then I'll run it on all wikis other than enwiki (since the main migration script hasn't been run there yet, it'll get done at the same time).

In T98625#1317336, @Glaisher wrote:

In T98625#1272873, @MarcoAurelio wrote:

By the way, it'd be good if it could only be used by registered users [...]

Special:Email is better in that case? ContactPage allows both registered and unregistered users to use it and doesn't have an option for specifically disallowing unregistered users.