This probably needs the SecurePoll schema files to be split in two, one for the tables on all wikis and one for the tables on wikis with local elections only?

Re-reading my first response, I realize I might have been a bit unclear. Indeed my focus was to respond to number 2, namely should it contain the shell username of whoever made the wiki? , not to question sending the email in the first place. I agree that this should still be sent. It's a notification as you say, not an auditing mechanism.

Sorry yes, I wrote that misleadingly, but I think @akosiaris and I are both addressing the question of whether the username needs to be in the email body. No objections to sending an email notification.

I think we are mixing two questions here:

I agree with @akosiaris (and thanks for the archaeology). It wouldn't be hard to implement this, but I think it's the wrong approach -- especially if addWiki.php is the only script using SUDO_USER, we should update the script rather than add an anachronism to pretend we're still using sudo.

BTW, on the technical side, mw-script does indeed keep the username in the labels of the job and the pod, e.g.

This functionality was added 10 years ago in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaMaintenance/+/a17c2ef30e0e85ced460f304cf481cdb7d924486%5E%21

@RLazarus Do you have any thoughts on how to tackle this one, please?

T393444 reports that (likely since this change?) emails are not being sent anymore to the newprojects mailing list when addWiki.php runs.

I think this is done. If there are any remaining issues, they can be split out into separate tasks.

I dropped api_feature_usage, bot_passwords and globalimagelinks in nupwiki. Someone in TSP says securepoll_log should actually exists and it's weird it's not in enwiki.

Not sure about securepoll_log but the rest of nupwiki tables missing in enwiki I'm sure needs fixing and removal.

Comparing it to enwiki, on enwiki there are following tables which are not on nupwiki:

Currently the following tables are created on wiki creation (nupwiki created in T390384):

In T352113#10641677, @Ladsgroup wrote:

bounce_records now fixed thanks to @Reedy and only cn_notice_projects left.

In T389064#10676087, @Tgr wrote:

Annoyingly, sendBulkEmails.php does not emails users who have unset the allowemail user preference ("Allow other users to email me") which is not really relevant for this kind of email. So I'll use a copy of it with a trivial change:

32c32,37
< require_once __DIR__ . '/WikimediaMaintenance.php';
---
> $IP = getenv( 'MW_INSTALL_PATH' );
> if ( $IP === false ) {
> 	$IP = __DIR__ . '/../../..';
> }
> 
> require_once "$IP/extensions/WikimediaMaintenance/WikimediaMaintenance.php";
235c240
< 		if ( !$user->canReceiveEmail() ) {
---
> 		if ( !$user->isEmailConfirmed() ) {

In T352113#10654272, @Umherirrender wrote:

Maybe all extensions listed as todo in T348573: All Wikimedia extensions that store their data outside the main database should use a virtual database domain can cause creation of tables in the wrong database, when the extensions is enabled at the install step.

Maybe all extensions listed as todo in T348573: All Wikimedia extensions that store their data outside the main database should use a virtual database domain can cause creation of tables in the wrong database, when the extensions is enabled at the install step.

bounce_records now fixed thanks to @Reedy and only cn_notice_projects left.

For both bounce_records and cn_notice_projects they can't be fixed because they are not migrated to virtual domains and have their own ad-hoc way.

Change #1123643 merged by jenkins-bot:

[mediawiki/extensions/ApiFeatureUsage@master] Fix wiring of schema change updates

https://gerrit.wikimedia.org/r/1123643

Change #1123643 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/ApiFeatureUsage@master] Fix wiring of schema change updates

https://gerrit.wikimedia.org/r/1123643

In T352113#10583681, @Ladsgroup wrote:

I had to drop so many tables created incorrectly in new wikis:

globaljsonlinks ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_target ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_wiki ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
cn_notice_projects ['idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
api_feature_usage ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
bounce_records ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']

Please do not create new wikis until this is fixed. cc @Zabe

I had to drop so many tables created incorrectly in new wikis:

globaljsonlinks ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_target ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
globaljsonlinks_wiki ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
cn_notice_projects ['idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
api_feature_usage ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']
bounce_records ['arbcom_zhwiki', 'idwikivoyage', 'kncwiki', 'satwiktionary', 'sylwiki', 'tigwiki']

Mentioned in SAL (#wikimedia-operations) [2025-02-26T16:19:57Z] <Amir1> dropping incorrectly created tables in new wikis (T352113)