I have listed seven identical problems in mw:Talk:Trust and Safety Product/Anti-abuse signals/User Info#Incorrect new articles count.

I think 6-digits numbers are as identifiable as 5-digits numbers, so you could avoid a mix of formats.

@WikiBayer and @Niharika: I don't know how duplicate tasks are managed, but I think this task is a duplicate of T398423.

I think this is more than a feature, I think this is a necessary correction.

Well, I think editors looking at User Info of AAA do not care whether AAA was granted IP access manually (+opt-in) or automatically. Moreover, I think editors will better understand the situation if the same text is used for all the cases (manually +opt-in / automatic / opt-out / automatic privileges removed). Moreover, we should avoid overloading User Info. So I think texts such as:

• Opted in to view temporary account IPs / Can view temporary account IPs
• Opted out to view temporary account IPs / Can no longer view temporary account IPs

should be simplified:

• View temp. account IP: yes
• View temp. account IP: no

My proposal of these new texts is consistent with another need, which is described in T398768.

About the received thanks: I agree, 1000+ should be displayed. And, to avoid overloading User Info, the given thanks could be removed. (I don't understand the benefit of seeing the given thanks.)

@kostajh 6 digits?

@kostajh the following temporary account has been created today. Is it OK?
https://fr.wikipedia.org/wiki/Sp%C3%A9cial:CentralAuth/~2025-100618

In T395661#10956786, @kostajh wrote:

I agree this would be useful, but let's do that in a different task, please.

Some users, to view temporary account IP, opt-in/opt-out in their preferences.
But other users don't use their preferences for automatic global access (Stewards, Ombuds, U4C, and Staff) or for automatic local access (CheckUsers and Oversighters). And the policy says: "members of a user group with automatic access who do not wish to have these access privileges should contact ca@wikimedia.org. Stewards are authorized to terminate access"

Now that there is only one access level, why keep two rights, ipinfo and ipinfo-view-full?

OK, @Johannnes89, thank you!

Thank you @Tchanders.
Well, this is not a big concern, this is a question, out of curiosity:
This task is called: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions
...and the task is closed. So why there is no information button, next to each IP address, in Special:AbuseLog?

@Dreamy_Jazz:
https://www.mediawiki.org/wiki/Extension:IPInfo says:

Information buttons are added next to IP addresses on history pages, the Special:Log page, the Special:RecentChanges page and the Special:Watchlist page.

I am not a temporary account IP viewer in it.wikipedia.org. But I activated IP Info in my preferences in it.wikipedia.org. And:
I see the information button, next to each IP address, in history pages, in Special:Log, in Special:RecentChanges and in Special:Watchlist.
I do not see the information button, next to each IP address, in Special:AbuseLog.

OK, thanks!

@Dreamy_Jazz
Yes it is in the log entry:

User rights log
12:33, 6 March 2025 NicoScribe talk contribs automatically changed his group membership: got checkuser-temporary-account-viewer; kept autopatroller unchanged

I am sorry, I thought that the rename would be done everywhere.

@Dreamy_Jazz:
I see temporary-account-viewer in https://meta.wikimedia.org/wiki/Special:ListGroupRights
I see temporary-account-viewer in https://meta.wikimedia.org/wiki/Special:CentralAuth/NicoScribe
I see checkuser-temporary-account-viewer in https://meta.wikimedia.org/wiki/Special:UserRights/NicoScribe
Is it the expected behavior?

One small note: users without metawiki account are much more common than users without loginwiki account.

• Hideo71, Andrepalma1, VidyaVenkat34, RachelMichelleTiller, Acharya sushil, Memenitalya, ComedyFan20013, Stepanyancycling, Orbital flowerz, found between 05:23, 9 May 2025 and 20:27, 8 May 2025
• MireilleBH123, Esthetio found between 17:46, 7 May 2025 and 14:11, 6 May 2025

OK, thank you @ArielGlenn!

Thank you @Tgr. Well, I am sorry, I thought that the accounts on loginwiki and metawiki were useful for other things (loginwiki for accounts synchronization when a user visit several wikis, and metawiki for OAuth use, with $wgMWOAuthCentralWiki in CommonSettings.php).

I am sorry to disturb you @ArielGlenn, but I have 2 small questions. Do you have logs available to investigate these cases? Will these logs still exist in 6 months, or in a year, if you want to investigate these cases later?

Thanks @ArielGlenn!
So the backfill jobs have been run several times to repair the following cases. Do you have logs showing the cause, when a backfill fails?
1 account for https://meta.wikimedia.org/wiki/Special:CentralAuth/Jenikipedia
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Furkan2525
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Nisapro
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Robertlanelilly
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Robertlane2031
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Fjshuxicjeb1
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/BobDobolina1

Thank you Framawiki for this task. Thank you Three_Sixty for the link to T220769. I've read T220769 and related tasks.

Thank you @DannyS712. But I still think that the option "excludezero" would be useful for all users.
I hope that it could be easy to create this option in MediaWiki.

In T215725#4952651, @Tgr wrote:

In T215725#4950163, @NicoScribe wrote:

But some people have no account on 'metawiki', for instance Hubert0482 and RalfU690717.

Yeah, bugs happen and might break local account autocreation temporarily. Also different wikis have different blacklists / abuse filters and those can block local account autocreation as well.

OK, thank you. I am just saying that it is not difficult to find other global accounts without account on 'metawiki': Bill Dance 22, Diane Sims Black, IanDBeacon 3, Larissa Cordova... Perhaps another Phabricator task should be created to investigate the bugs / blacklists / abuse filters, that are preventing these local account autocreations on 'metawiki'.
(And there are also old global accounts with recent activity but without account on 'mediawikiwiki + metawiki': Fear3235, James265, Saphomicron.)

It seems that you consider that a local account on 'metawiki' is autocreated, when a global account is created.
But some people have no account on 'metawiki', for instance Hubert0482 and RalfU690717.

I am sorry, but I think that the community does not know about the possibility to thank for flow-lock-topic and flow-restore-topic. And I think that the reasoning "I want to thank Foo for resolving this topic... No 'thank link' is displayed in the topic... No 'thank link' is displayed in the topic's history... I have to search for a 'thank link' in the public logs..." is too long (and complicated) for the contributors.
So I think that the 'thank link' should be displayed in the topic's history.

In this example, I was unable to thank for the edit of a topic summary of a structured discussion. I do not see the associated log type in the description of this task.

In T60485#2249703, @MGChecker wrote:

My preferred use case would be thanking file uploads. Furthermore, I would like to use it to thank sysops if I ask them to use their rights to do something for me, so deletion, rights and protect log would be nice options too.
If I think about ist, maybe thanks for blocks should only be an option since a block is a really destrucitve action. I imagine really weird situations about users thaning sysops because they blocked another user thex don't like...

What "weird situations" are you supposing?
Let's suppose that Foo and Bar hate each other, and each one has a "fan club of contributors", and Foo opens a request against Bar, and the sysop Baz blocks Bar due to the request. What kind of harassment/trolling (in the block log) are you supposing? The "Foo hooligans" would thank Baz in the block log? The "Bar hooligans" would dishonestly thank Baz in the block log?

In T60485#2249703, @MGChecker wrote:

My preferred use case would be thanking file uploads. Furthermore, I would like to use it to thank sysops if I ask them to use their rights to do something for me, so deletion, rights and protect log would be nice options too.
If I think about ist, maybe thanks for blocks should only be an option since a block is a really destrucitve action. I imagine really weird situations about users thaning sysops because they blocked another user thex don't like...

I do not understand the hesitations about the log type "block" (and "gblblock" and "gblrights" and "globalauth").
A block can be seen as a "destructive action". But a deletion can be seen as a "destructive action" too. And these two actions can also be seen as "positive actions", because they protect the Wikimedia projects.
I suppose that the hesitations should be about consensual/contentious actions, instead of positive/destructive actions. But all the actions can be considered contentious (by some users): there are contentious blocks, contentious deletions, contentious moves, contentious protections, etc.
I think that most of the actions are not contentious, and that most of the contentious actions do not lead to harassment/trolling, and that the sysops have the necessary experience to handle these situations. So I think that we should assume good faith (of the contributors who just want to thank the sysops) and allow 'thanks' for the log type "block" (and "gblblock" and "gblrights" and "globalauth").

I understand the reasoning to disallow 'thanks' for some logs (such as User creation log and Thanks log, because it can be confusing). But I see no reasoning to disallow 'thanks' for these log types:

• abusefilter
• gblrename
• renameuser
• stable (for the pending changes log).

There is the same problem on Wikipedia in Italian, cf. https://meta.wikimedia.org/wiki/Talk:Community_Tech/Ping_users_from_the_edit_summary#Reverts_to_last_edit_by_XXX
There is the same problem on Wikidata: I have been notified for the edit https://www.wikidata.org/w/index.php?title=Q1420&oldid=prev&diff=650083501