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, 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.

MacBook Pro 2017, macOs 13.2.1. I tried this with Safari Version 16.3 and Google Chrome Version 111.0.5563.64

@jrbs what's odd: I voted this morning, but clicking on the SecurePoll link right now, it says I'm not eligible. So either your list of voters must have changed somehow during the day or something different is wrong with the tool.

Note: This bug seems similar to T173569

+1 my default filter options (looking for latest revisions by IPs/Newbies) are still timing out most of the time and weren't before this bug was reported
https://meta.wikimedia.org/wiki/Special:RecentChanges?userExpLevel=unregistered%3Bnewcomer&hidebots=1&hidepreviousrevisions=1&translations=filter&hidecategorization=1&hideWikibase=1&hidelog=1&limit=50&days=1&urlversion=2

@matmarex is this bug possible related? There shouldn’t be a „new topic“ discussion button at the main page and there should only one button at discussion pages

I think T205689 fixed it. I don't see any more problems, visual editor and source code are working fine.

This problem occurs in all namespaces and in all articles, not just those with pending changes / „unchecked“ box. So the bug is likely caused by changes on the wikitext editor or perhaps the new vector-skin?

There is a similar problem with Wikitexteditor 2017: When using the search option, wrong parts of the page are being highlighted – see https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/R%C3%BCckmeldungen#Erneut:_Fu%C3%9Fnoten or this screenshot https://commons.wikimedia.org/wiki/File:Wikitext_2017_editor_bug_on_selecting_text.png