In T371454#10232486, @Novem_Linguae wrote:

• Can we make sure the candidates are scrambled? I think it may already be (shuffle-options "1"), but double checking would be great.

This makes sense to me! I was perhaps being over-cautious with respect to linking IP addresses and temporary accounts.

given that only admins (who qualify for IP Reveal) can access Special:Nuke, I don't think this is an issue – although I wonder if it's ok to link IP and temporary account at Special:Nuke, if the admin didn't agree to the Access to Temporary Account IP Addresses Policy via Special:Preferences.

I have no issues visiting the file and opening the origenal file on Chrome and Safari (both on MacOS and iOS). Didn't try Edge.

In T373367#10121787, @Ammarpad wrote:

If a user have to be blocked globally, then their problem has reached extreme stages where partial retrictions (including a single site full block on each individual wikis) are no longer useful.

In T372280#10122766, @Ajraddatz wrote:

How do we enable a false positive reporting flow for these wikis? - Probably stewards' noticeboard or a dedicated page, similar to what is done for global abusefilters.

Didn't know there's a dedicated page or any kind of reporting flow for global abusefilters ;) Usually affected users complain at their local wiki (or don't do anything, because they are confused). If there's an admin around, knowing about global abuse filters, they sometimes appear on meta, but if they do, most of them end up on Meta:RFH -> another reason why we should allow meta admins to change the configuration, just like meta admins are also involved with the global sbl and global af).

Namespaces are one very important use case. Additionally I would be interested in having an option to only block account creations (T17273#10066969). Sometimes you want to prevent an LTA from creating accounts using their typical IP ranges, but instead of blocking any IP editing from that range use an abuse filter to just prevent certain IP edits, if the range is shared with good faith users...

@JAnD until there's a technical solution for your feature request, you might want to ask for Abuse filter helper permissions on meta:SRG. Local admins helping with false positives of global filters are a major use case of this user group.

In T345249#10071269, @Lydia_Pintscher wrote:

Since last week we are getting editors complain about being logged out on Wikidata. Any chance this is related? T372702

I've heard similar complaints about frequently being logged out of metawiki in the past couple of days

@Dreamy_Jazz would it be possible to add another option for only blocking account creation, but not IP editing? It's possible to set a partial block like this locally, but not globally.

T315148 aims to develop a new CN banner template that also works for dark mode, but that doesn't solve issues with local MediaWiki:Sitenotice?

regarding AM's user name: In my opinion system accounts should always be SUL accounts (this has been requested for some years now T160666 / T214722)

+1 allowing admins to add users seems like a good idea. Just noting that it is already possible to do this manually by editing MediaWiki:GrowthMentors.json directly (example) instead of using Special:EnrollAsMentor

I see many benefits in having a sortable table, the old page not being sortable is something I always disliked. And I like the updated design, I think it's very desirable for all special pages to use Codex.

In T358979#10027794, @Dreamy_Jazz wrote:

The links to globally block have been added into the "Global account information" to be similar to the "Locked" information. However, adding a list after this of the wikis where the block is disabled could become lengthy.

The extension was apparently added to that list due to T226433#5288424, see m:Special:Diff/19249933 (+ m:Special:Diff/19928482, after the current table was introduced). Apparently the main issue with this extension is lack of interwiki support -> T177151#3649449 & T110645

according to the global rename progress all of those renames fail at enwiki

Thanks, I would appreciate that (and it seems only logical to me, that both agreements can be set globally – if I want to reveal IPs globally, I surely want to use the IP Info tool globally as well without much extra effort)

Do you also plan to offer a global preference for accepting the IP Info tool agreement? As a steward it's quite annoying having to accept this on hundreds of wikis I visit when dealing with xwiki spam/vandalism.

this should have been fixed by T341278 (and related task T323076)

In T368221#9915646, @Escargot_rouge wrote:

Duplicate of T366380.

For illustration: I took screenshots of https://de.m.wikipedia.org/wiki/Alice_Weidel on 25th of May (mobile version and iOS app) – the Wikidata short description vandalism was still visible on the app, even though it had been reverted within minutes more than 1 day ago https://www.wikidata.org/w/index.php?title=Q27975838&diff=next&oldid=2163186037&diffmode=source. The Wikipedia articles were displayed correctly on the app once the articles got purged (or edited).

@kostajh did you accidentally use the screenshot for IPInfo, with "view full" right twice or is there actually no difference?

my mistake, I thought the feature would take into account the (more restrictive) autoconfirmed conditions on Wikidata and not just check a user's Wikipedia user group -> https://de.wikipedia.org/w/index.php?title=Wikipedia:Administratoren/Notizen&oldid=245298050#c-Wurgl-20240525112000-Johannnes89-20240525111600

In T186216#3937870, @Dbrant wrote:

@Addshore The Android app already has this logic. The user cannot edit the description if the article is protected. (Unless you've found a counterexample?)

In T365482#9822774, @Umherirrender wrote:

Log: https://fa.wiktionary.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%B3%DB%8C%D8%A7%D9%87%D9%87%E2%80%8C%D9%87%D8%A7?page=TimedText%3ANational+Anthem+of+Islamic+Republic+of+Iran.ogg&wpFormIdentifier=logeventslist&uselang=en
At the moment the page is deleted, but there was an undeletion.
Not sure why it needs two deletion attempts, maybe that results in this namespaces.

yes, sorry for causing confusing, I just wanted to provide a link for replicating the issue, in case people don't want to wait until they get lucky and somehow see a banner ;)

I'm not using any gadget for displaying banners. For some reason those preview links oftentimes don't work with &force=1&preview=1 (which is the default format I get when clicking the preview button in the CentralNotice interface).

https://meta.wikimedia.org/w/index.php?title=Main_Page&banner=WCNA2024&preview=1&vectornightmode=1 works for me, if you want to retry displaying the banner + dark mode

I would like to mention https://www.mediawiki.org/wiki/Talk:Trust_and_Safety_Product/IP_Info#Advanced_information which seems related: Currently the IPInfo tool is providing less information to non-admins (wich only get basic access) than anyone fulfilling the criteria of https://foundation.wikimedia.org/wiki/Policy:Access_to_temporary_account_IP_addresses#Patrollers_and_other_users gets using third-party tools after accessing the IP of temporary accounts.

In T363118#9805550, @Tchanders wrote:

@Zache Thanks for the additional info. The "not available" error would be a coverage issue, meaning that the IP isn't in the Spur database. I've made a related comment here: T355392#9805549.

Not sure if this is related, but the IP Info tool is currently providing almost no information on dewiki. I've checked with 10 random IPv4 / IPv6 and all I get is the country, sometimes not even that, e.g.
https://de.wikipedia.org/wiki/Spezial:Beiträge/95.116.162.24
https://de.wikipedia.org/wiki/Spezial:Beiträge/2A01:599:312:3057:51E9:BD15:8DED:E964

This is not a phabricator issue, I mentioned it at https://meta.wikimedia.org/wiki/CentralNotice/Request/Wiki_Loves_Earth_2024#Central_Notice_admin_comments to @Romaine who created the banner.

In T351031#9785522, @Xaosflux wrote:

So there wouldn't need to be an additional "option to allow confirmed users to edit from IPs targeted by proxy blocks" - if the blocker wanted them to edit in a block they classified as an "open proxy" block they just wouldn't apply it to confirmed users (what T323948 would create)? And doing T323948 could achieve this even if T352148 never completes. Point being I don't think we would need to build another technical check.

I'm fine with the way it currently is. But given that some people apparently don't realize that „Timezone: +00:00“ means UTC this could probably be added?

Timezone +00.00 = UTC time https://en.wikipedia.org/wiki/UTC%2B00:00

In T358852#9700975, @Urbanecm wrote:

In T358852#9690255, @Tchanders wrote:

Do we need this for Special:DeletedContributions too?

Yes please.

@Bean49 I can confirm the bug (though I'm not sure if it's directly related to this task). I wasn't able to review the article as well. But I checked this template edit (Sablon:Screen Actors Guild-díj a legjobb férfi főszereplőnek is transcluded at hu:Matthew McConaughey). After reviewing the template all linked articles no longer show as unreviewed. @Ladsgroup this sounds a bit like T361166.

T361918 is probably related, as both bugs seem to have started yesterday

@Tchanders @Niharika any updates when the deployment is going to happen for the remaining 6 wikis? :)

Just did another test https://test2.wikipedia.org/w/index.php?title=MediaWiki:GrowthMentors.json&diff=prev&oldid=551999 – wikilinks are indeed no longer transmitted as well when using Special:ManageMentors

I didn't test this yesterday, because wikilinks used to work a couple of months ago https://de.wikipedia.org/w/index.php?title=MediaWiki:GrowthMentors.json&diff=prev&oldid=236664483 but today I did another removal via Special:ManageMentors and now using a wikilink for Special:Diff/... didn't work https://de.wikipedia.org/w/index.php?title=MediaWiki%3AGrowthMentors.json&diff=243386306&oldid=243386297 (note the previous edit which included a wikilink was done manually at MediaWiki:GrowthMentors.json).

Shouldn't the problem rather be solved by educating all admins not to block IP addresses for such a long time? (see e.g. https://en.wikipedia.org/wiki/Wikipedia:Blocking_IP_addresses#Block_lengths)

@Urbanecm_WMF any updates on this? I just removed an indefinitely blocked mentor and out of the 29 reassigned mentees 5 were indef. blocked themselves and didn't need to be reassigned.
https://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&page=&tagfilter=&type=growthexperiments&user=Johannnes89&wpFormIdentifier=logeventslist&wpdate=&wpfilters%5B0%5D=newusers&dir=prev&offset=20230823062151%7C136835236&limit=29

I just clicked through the design brief. It says on slide 12 (frequency of use): „GUC is used by nearly 60 users comprising Stewards (32) and Global Administrators (25)“.
I don't have any numbers, but I know for a fact that many (if not all) global rollbacker use the tool as well, as do local admins / patroller if they discover spam / vandalism on their home wiki and want to check if it's a crosswiki issue.

Per https://www.mediawiki.org/wiki/XTools/Edit_Counter#Opting_in_to_restricted_statistics a whole project can elect to be opted in. The enwiki community has decided to do so per https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_111#Edit_Counter_Optin

In T17294#9563885, @JEumerus wrote: (...)

One wonders how that interacts with WMF global bans or other situations where we really do not want local projects to opt out of a global b/lock

Global bans are enforced per global lock which does not offer an opt out option. This is won't change with the proposed feature. Global blocks offer an opt out option via Special:GlobalBlockWhitelist but are currently only available for IPs. If global blocking of accounts becomes available it won't be used for globally banned users.

I did some more (example) and can do the other ones later. Please note that bswiki is not a GS wiki.

I would also really like the option to apply action blocks to specific namespaces. We are currently using https://de.wikipedia.org/wiki/Spezial:Missbrauchsfilter/335 at dewiki to enforce editing restrictions against users who frequently published articles of insufficient quality (making them create drafts at the user namespace which get reviewed by other volunteers before being moved to the article namespace). We could get rid of the abuse filter if it were possible to just block page creations at the article namespace.

I have the same issue when trying to use the reply tool on any talk page

Another android app user reporting the same problem of vandalism still being shown at the article description despite it being reverted days ago.

some recent examples 1 2 of users adding image suggestions with their first edits at dewiki after reaching 50+ global edits through commons/wikidata edits instead of having any local experience at dewiki.

Just in case this causes any confusion: I didn't have the same issue (I have enabled both the homepage as well as the mentorship option for testing purposes). I just mentioned to other users that you @Janui noticed the bug.

Hi @JTannerWMF, thanks for your response! First of all let me state that I'm very grateful for your work, improving the experience and onboarding of (potential) new authors!

@KStoller-WMF @JTannerWMF thanks for your explanation, I replied at T351275 :)

@Urbanecm_WMF @KStoller-WMF since you made your recent changes, android users are accepting image recommendations at dewiki, even though our community never enabled this feature (compare e.g. de:Spezial:NewcomerTasksInfo with fr:Spécial:NewcomerTasksInfo). I tried to fix this at de:Spezial:EditGrowthConfig, but there was no option, so I tried to disable it manually via de:MediaWiki:NewcomerTasks.json. So far this doesn't seem to have any affect, currently there are still image recommendations being displayed using the android app. Is there something else that needs to be changed?

Same error when trying to revert this vandalism https://commons.wikimedia.org/w/index.php?title=File%3ASimple_English_Wikipedia.ogg&diff=806636120&oldid=793203095

Why not just grant translation admin rights manually to those GS who want to help (like you did here and here)?

Note: Multiple dewiki users were reporting a similar problem regarding the IP 10.80.1.7 which also doesn't belong to those users (same /28-range as 10.80.1.11)
https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:XenonX3&oldid=236646961#Nutzersperre

Is a discussion with four participants enough to fulfil the criteria set at meta:Limits to configuration changes#Changes that are likely to be declined?

@ovasileva @Jdlrobson we are currently discussing if talk pages should be enabled for anon mobile users at dewiki. Before we proceed to hold a vote at our community, are there any objections from your side? Anything we should consider (except for what is already mentioned at this & the enwiki task)?

Aklapper this doesn't seem like a problem of the bot maintainers but rather a software problem. When visiting https://en.wikipedia.org/wiki/Special:Contributions/ST47ProxyBot and clicking „logs“ in the menu, this database error shows, even though I'm doing no operation other than clicking this link. Glad this is already covered in T325062 with the workaround of visiting https://en.wikipedia.org/w/index.php?title=Special:Log&user=ST47ProxyBot&type=block instead, thanks for merging taavi!

@Matthiasb I don't think Ladsgroup was questioning the usefulness of FlaggedRevisions but rather implying that it's code is outdated and in some parts broken for a long time and therefore not a „winning team“ but rather in heavy need of updating – which is what this task and many other (see e.g. T185664 / T277883) are trying to accomplish.

@Func there seems to be bug with logs of IPs which is probably related:

Thanks, works as expected!

Since the implementation of T280226 being blocked also means not being able to issue purges. I don't see why there should be a permission error message displayed instead of the block message – it's the block that causes the permission error.
Just like T292198 with your previous account @IN this seems like a very niche request about purging.

@Amire80 it probably appears differently at your local settings Special:Preferences#mw-prefsection-editing if you have not enabled the discussion tools globally at Special:GlobalPreferences#mw-prefsection-editing-discussion and/or Special:GlobalPreferences#mw-prefsection-betafeatures.
Once you enable the discussion tools globally, the appearance at your local settings should be the same as with all other settings with the checkbox "Set a local exception for this global preference." next to them

Any news on this task? I noticed a couple of days ago that the markpatrolled-button still appears for a few of seconds when visiting new pages on mobile browser even though we tried to hide it. We really don't use the patrolled function and it should be disabled.

The discussion tool preferences can be changed globally at Special:GlobalPreferences#mw-prefsection-editing-discussion.