Closing, this was resolved some time ago :)

T&S can support. You can refer people affected to ca@wikimedia.org and we can investigate their situation.

This exists now! It is not hosted anywhere just for safety reasons.

We no longer use this parameter since it broke some user scripts for not much benefit.

In T425761#12169104, @Novem_Linguae wrote:

Thanks for the quick response. One workaround would be to add these folks to the eligibility list instead. Thoughts on that? Or is the idea that the eligibility list gets updated multiple times and you don't want to accidentally overwrite the override list people?

Override list is still useful for when we need to add e.g. zero-edit staff accounts to active elections (i.e., people missed in the original pull). So I would like to keep it if possible.

In T425796#12074319, @Bugreporter wrote:

In T425796#12038981, @EMill-WMF wrote:

The page was updated on June 9 to remove the link.

I believe this is not enough; I have complained at https://meta.wikimedia.org/wiki/Meta:Requests_for_help_from_a_sysop_or_bureaucrat#c-GZWDer-20260628182200-Help:Account_recovery

In T430872#12077886, @TLepage-WMF wrote:

I believe you are right, apologies for the lack of precision, still getting my footing among the various account types! I indeed have the same problem when trying to log in to mediawiki.org.

Is this still the right place for disabling 2FA on the SUL account? And thanks already for such a quick response!

Done!

Yep fine with me. I was just being overly cautious :)

Indeed it was a size issue, splitting it into four helped fix this.

Unfortunately I can't seem to use the file with importGlobalVoterList.php because it's too big for k8s (I think that's what this means):

In T423547#11923609, @Novem_Linguae wrote:

Someone should probably check the times those accounts became qualified to vote. I wonder if they all fall near or within the couple hour window where the tools were running. For any tool that takes hours to run, and runs on 1000 wikis, tool A might check eligibility at 8AM, and tool B might check eligibility at 10AM, leading to slight differences in the results, without actually being a bug.

OK, it seems that 68814 people qualify using the regular process, a difference of 19 users.

Thanks @SD0001 - only two errors in the file:

2026-05-07 22:13:04.530 ERROR: [s5] [urwikisource] Error while connecting: Access denied for user 's56852'@'%' to database 'urwikisource_p'
2026-05-07 22:13:04.531 ERROR: [s5] [urwikisource] Failed: Access denied for user 's56852'@'%' to database 'urwikisource_p'

I've set these in motion today (with ucoc2026PopulateEditCount.php on all 8 sections) in parallel with @SD0001's tool (T423547).

Oops, sorry, this was unsent:

In T423547#11828822, @SD0001 wrote:

• ./cli --election config/ucoc-2026.yaml generateList > data/ucoc-2026/logs.out

This remains low-priority I think, assuming this is display only, but is still happening:

I'd like to try this for the U4C votes since we have the scripts as backup (T423528). We cannot do so until the cutoff for eligibility on April 24, but after that I'd happily give these steps a try.

In T423528#11827470, @Novem_Linguae wrote:

Same caveat as that task: I understand this is discouraged behaviour now (see T355594: For global elections, stop creating eligible voters table for each election on every wiki and keeping them forever) but there is no alternative at the moment.

@SD0001 wrote a tool to grab voter info without creating SQL tables. T399418: Request creation of voterlists VPS project. Maybe not for this election, but that might be a good tool to try on a small, low risk global election, and then if it goes well, adopt its use more widely. That could begin the process of transitioning off the "create 1000 tables" model of populating global election eligible voters.

Yes - the results are:

Just in case there are still concerns with the above I have set it to start at 06:00 UTC on *Thursday*. We can move it again if necessary before the poll begins, but it is harder to move it after it has already started.

I can set this up (it will be quite tight for Nahid I think if you want to start it this soon).

In T415482#11555028, @Ibrahim.ID wrote:

إسلام

Could I please ask that this conversation move to a more appropriate venue? This task has been declined for a while now.

In T398299#11202639, @Novem_Linguae wrote:

I'd support removal. In another ticket, Dom suggested asking @jrbs if they use the feature. If they say no, then I think that'd be a green light for removal.

In T412254#11448626, @A_smart_kitten wrote:

I may be wrong but I think you might be able to create a Phab project for this tool from within Striker

Yes, but we are getting 15-20 duplicate emails per day, and this is quite a burden on our small support desk.

This is actually handled entirely by triggers apparently :) I have set those up and I believe all is well.

In T355594#11378867, @Ladsgroup wrote:

@jrbs can I drop securepoll_u4c2025_edits everywhere now?

I believe this is resolved with Tran's work above. Thank you so much.

To clarify, this is referring to the Echo notifications and not the emails sent with sendMail.php, which open with Dear $USERNAME, I think. It may require upstream changes to how Echo distributes email since if I remember correctly it is not possible to include variables in these messages.

Yes, that sounds fair. A good thing to clarify for the 2027 cycle as well.

I filed T407526 for this. The issue is that I forgot to remove those who added their names to the list since the first mail. I apologise for that oversight.

I saw this was reopened and I think I know why. The script uses the nomail list when it is compiling the list for the first time. Reminder emails use that same list.

We plan to run a "reminder" notification as well. I'll file a patch just replacing these messages but I'm not sure what the actual best path is for that.

I added this to the voter info blurb:

Indeed I apparently triggered the first log and get a similar error now:

In T400243#11265107, @Dreamy_Jazz wrote:

Is there a sense of how urgent this is to fix?

Is there a button / link to a noJS view? I'm really hesitant to just disable the drag-and-drop for everyone since it is much more intuitive as a voting solution and works for the majority of people.

I only ran into this once, doing it again seems to be fine.

I guess the quickest solution might be to force noJS view on mobile (even on the desktop view) but I have no idea how easy that is.

These are sending now. Thank you!

Woops, I was querying the wrong table.

This might just be me being stupid since JSutherland (WMF) is in there (that's me!) but I definitely have not voted with that account. So possibly my SQL query is incorrect.

Board vote has indeed started! But I think generally we shouldn't push anything while that is open either, in case it causes a regression that impacts the results.

In T406374#11243555, @Novem_Linguae wrote:

To clarify, does this bug happen before or after clicking "Edit Poll"?

After, on the poll creation / edit screen.

In T406375#11242844, @Pppery wrote:

It won't impact the election. The SecurePoll pages are read-only mirrors of what's actually stored in the database, and are not used as a source of truth.

I'm not sure if this would impact the election (the config appears to be saved correctly so it is probably fine?) but would really appreciate PSI have a quick look at this just in case.

Now that it is October my edit count seems to be fixed. Seems that's not true for everyone?

I have basically resolved this with an Apps Script function. We can focus on T399742

This is done!

Hi @Dzahn, sorry for the vagueness of the request.