So here's the thing - workflow wise, "Special:Contact/Stewards" just goes to our VRT queue, the same way if you just email the queue address directly; which is open to anyone - who can trivially spoof anything. That VRT queue also sends a mail receipt - so yes, you can use this form - or just plain email - to get VRT to send a receipt to anyone else. VRT doesn't have any special indicators for authenticated sources of mail and it is quite rare that we would open and examine the envelop headers.

In T224059#10225614, @Ammarpad wrote:

When this task was filed it was not possible to disable editing the sender name and email address. After T324175, these fields can now be independently locked from editing, so the issue is now purely form configuration not ContactPage extension limitation.

It it's still needed to disable these fields, this is Wikimedia-Site-requests otherwise it should be closed as needing no action.

@JJMC89, can you speak for stewards to answer these questions?

1. Should https://meta.wikimedia.org/wiki/Special:Contact/Stewards require login to work?
2. Should users be able to edit the email address field?

You will get 3 columns, values -1,0,1; labeled however you want them. One of them must be specified as the default. Unless otherwise specified in your rules, it should be the abstain/neutral one. (So if all someone does is open and submit the ballot, it is all abstains).

FYI: SP doesn't support the feature being asked about "add a column sorter for options" - a feature request would be needed for that:

Yes, generally WMF will set up the election and will load the candidate names when provided. Then an election admin can add the electoral roll (voter whitelist), or the roll can be given to them to do.

Users are continuing to report this problem:

FYI, most of the 2023 enwiki arbcom settings can be seen in the public onwiki config files here: https://vote.wikimedia.org/wiki/Special:PrefixIndex/SecurePoll:1436

Normally the WMF resource does this task on votewiki, as they also need to deal with the encryption stuff

@Novem_Linguae you want to use the same mechanism as the 2023 enwiki arbcom election correct? If so that was:

Readers reporting this is still going on, clicking on an image: "...it starts large, then when I click it becomes smaller, then if I click again, it chooses a third medium size..."

The inverse of this needs to be able to happen as well - automatically revoke this from any user that is no longer in the required groups on any prod wiki

A reader reported similar problem on en.wikipedia in ticket 2024100510006742

Yup, <templatescripts> (akin to <templatestyles>) seems much cleaner.

Just noting that with one of the original examples resolved in another task, an example with >25000 mentees IS completing on a basic api fetch: https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Dreamyshade

No rush

In T330071#10190666, @Urbanecm_WMF wrote:

FYI, I just deployed the fix for that one to production. https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf now works. I'll try to readd and then re-remove the user to the list of mentors, to see what happens the reassignment. Hopefully, this was all it needed, but if not, we can investigate further.

In T265726#10170351, @Ameisenigel wrote:

Could we re-open this Task? According to https://foundation.wikimedia.org/wiki/Policy:Access_to_nonpublic_personal_data_policy/Exceptions the legal issue should be resolved.

Still seem to be having issues with this. On 2024-08-07 on enwiki, we removed a retired mentor, User:Blaze Wolf :

Agree on change from onhover to onclick to open this, it is overly intrusive

Initial community discussion (not very well attended, but well advertised) does not have support for flagging actions/edits as 'bot'.

That other tasks suggests there are triggers that will let this work already, perhaps they can be repurposed?

(Straying off topic of this ticket which if it is a duplicate should certainly be merged in)

@Tufor (see image below) - however if you are referring to how it looks when it is NOT poped-up, that should be a different bug report (I agree it looks really bad there, as in the image below)

<grips>Prehaps - ticket may be another victim of our lack of an incident management system.... </gripe>

For example, oops don't stray a few pixels from trying to use the coordinators indicator:

At the very least perhaps this should require an unclick instead of an onhover, as attempting to hover any of the other indicators in the area is likely to lead to continual popups of flagrevs even if you have no desire to use that function at the moment.

Just tried, browser print to Letter and A4 both seem to be on the same page now. PDF writer is still completely different - using a larger font it seems, splitting the infobox to multiple pages - but much closer to the 'old behavior'. This user story does seem to be solved now, however there may still be some oddities going on with the pdfmaker.

That may work project wise, but is there a different issue of why this browser-print-to-a4 doesn't match electron print to a4?

For webui, this would be on-demand and certainly could be restricted to privileged users (suggest reusing some existing permission related to ipinfo) so I wouldn't expect the rate limit to be much of an issue, likely could use existing general webui rate limiter. API - would need more discussion, and starting with webui only would solve the initial user story of looking for a replacement for other deprecated gui tools.

Possible integration with T349534

A PDF reader shows:

"Electron PDF seems to think it's dealing with less than 720px worth of space"

OLD VERSION:

Recent user story matching this at: https://meta.wikimedia.org/w/index.php?title=Talk:The_Wikipedia_Library&oldid=27444592#Automated_message_that_I_am_eligible_for_the_Library,_but_then_-_I_am_not_eligible,_after_all

May be a subset of T354117

See also https://meta.wikimedia.org/wiki/Talk:The_Wikipedia_Library#Automated_message_that_I_am_eligible_for_the_Library,_but_then_-_I_am_not_eligible,_after_all

Thank you for the update!

Confusing request left for enwiki community at: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1245192151#Cleaning_up_MOS%3A_links - can someone clarify there in a way that is very clear to editors about what is changing, what is breaking, etc.

Similarly the mobile web interface does not have the "watch this page" option, but only when using source editor publish screen - in VE publish screen it is there. Suggest this gets solved at the same time as the original story here by bringing parity to the publish controls regardless of editor selection.

c.f. T372024 about if this account should be +system, +bot

Just need to test this now

Is this resolved in production? We are still having readers complain about this problem:

Yes, then it grew in to self-service. AFAIK, the ones manually from Legal still just come to the VRT queue?

Thanks for opening this, this workflow certainly needs to be improved.

Simply allowing multiple, overlapping protections on a page would solve for this and other use cases.

Also, you could script callling Special:Createlocalaccount for an account to import it to a local project

Note: initial comments suggest not to use 'bot' assertation, feedback welcome on the link above.

@HMonroy can you provide additional information on this ask? Is this only about a specific UI element, not the underlying blocking capability?

https://meta.wikimedia.org/wiki/Meta:Requests_for_bot_status/AccountVanishRequests opened

Using the existing last modified and license sounds like an easy win (and helps to propagate the open license as well).

See also T157844

2FA audits are being performed by WMF/stewards against required groups - so this may be solved. The results of such audits are not published publicly.

Note https://foundation.wikimedia.org/wiki/Policy:Access_to_nonpublic_personal_data_policy/Exceptions has been updated to remove a hurdle for 'crats to be able to do this; at this point would need a new task - the "MediaWiki:Verifyoathforuser-text" message should likely be initiated along with such a request, to put in a warning to users that the results of that query are non-public information - at the very least for WMF wikis (if worded generically enough could be reusable).

any objections to at least initially flagging this account as bot on metawiki while this is being worked on?

Not a bug, existing feature, updated documentation.

Thank you for the update, regression marker withdrawn. Updated the documentation at https://www.mediawiki.org/wiki/Help:Preferences#Editing

(removed teahouse item, as it is no longer running at reference project)

@Jdlrobson the Teahouse listing above appears to have been deprecated, OK to remove from here?

Note: added electron incase this system is needed to pass that value on to proton, if it wouldn't be please untag that project.

AM is already going to run based on on-wiki local .json files correct?

Lock actions are not secret, so this is certainly not an inappropriate information disclosure problem; no issues with it being turned off if it is useless noise though.

Just for search notes, this was delivered as Special:GlobalVanishRequest

In T371499#10033897, @JScherer-WMF wrote:

In T371499#10033398, @Xaosflux wrote:

From a RACI perspective - who is Responsible for acting upon the reports? Because they are a key stakeholder. Is WMF staff taking this responsibility? If this is something that per-project volunteers are expected to manage, they likely need to end up on-project.

That's right. It needs to be per-project volunteers because the issues are primarily created by hardcoded colours in volunteer-maintained templates which we don't maintain. On the projects that you work on, where would you want to see these reports, and what would you like them to include?

From a RACI perspective - who is Responsible for acting upon the reports? Because they are a key stakeholder. Is WMF staff taking this responsibility? If this is something that per-project volunteers are expected to manage, they likely need to end up on-project.

More questions:

In T370679#10021473, @Niharika wrote:

@Xaosflux Would you consider this change sufficient to close this task?

It this already done, or something more specific in the UI than the title suggests? Admins can already place p-blocks on multiple namespaces:

(Screen shot on merged in duplicate T371151 )

FYI: Customers are still complaining that they can't "report" any details of their problem ( from https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=13268092 )

Not following where this will fail to appear?

In T370679#10006226, @Niharika wrote:

In T367329#10005388, @Izno wrote:

the system moving users is not flagged as a system bot like e.g. the Maintenance script user.