In T9500#193867, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/60

This is now done within RemovePII, it will be deployed alongside our 1.38 upgrade, as it won't work on 1.37.

https://github.com/miraheze/RemovePII/pull/57

In T8949#181345, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/54

https://github.com/miraheze/RemovePII/pull/54

Moving to long term for now. Please move back to triage when you have a better idea of timelines on when software will be ready for us and the turnaround you want.

What actually is TSPortal in terms of software implementation?

https://github.com/miraheze/MirahezeMagic/pull/285
https://github.com/miraheze/puppet/pull/1961

https://gerrit.wikimedia.org/r/c/translatewiki/+/719181

In T7992#161253, @Dmehus wrote:

https://phabricator.miraheze.org/T7995#161251

Regarding this, @Universal_Omega, what do you mean here? When we used the removepii.php script, the CheckUser log data for the bottom line is removed.

In T7995#161251, @Universal_Omega wrote:

In T7995#161250, @Dmehus wrote:

In T7995#161249, @Universal_Omega wrote:

In T7995#161248, @Dmehus wrote:

In T7995#161247, @Universal_Omega wrote:

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

Yeah, was planning on waiting at a few more days at least. But the fix in that task, is also an issue in the script so isn't necessarily a blocker. That is actually what made me think of this, as the fix would need to be added to the script if we are keeping it as well.

Okay, sounds good. :)

I know it's not a blocker, I meant just in terms of keeping the script's code in case we need to import some of it into the extension.

All of the script code is already in the extension (implemented in a more modern and clean way though).

But not all the extension code is in the script.

Ah, okay, makes sense. That's good. I just wasn't sure because of the bug that exists in T7992, but you did say it was implemented in a more modern and clean way,

The bug that exists in T7992 also exists in the script.

Replied on T7992.

Regarding this, @Universal_Omega, what do you mean here? When we used the removepii.php script, the CheckUser log data for the bottom line is removed.

In T7995#161250, @Dmehus wrote:

In T7995#161249, @Universal_Omega wrote:

In T7995#161248, @Dmehus wrote:

In T7995#161247, @Universal_Omega wrote:

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

Yeah, was planning on waiting at a few more days at least. But the fix in that task, is also an issue in the script so isn't necessarily a blocker. That is actually what made me think of this, as the fix would need to be added to the script if we are keeping it as well.

Okay, sounds good. :)

I know it's not a blocker, I meant just in terms of keeping the script's code in case we need to import some of it into the extension.

All of the script code is already in the extension (implemented in a more modern and clean way though).

But not all the extension code is in the script.

Ah, okay, makes sense. That's good. I just wasn't sure because of the bug that exists in T7992, but you did say it was implemented in a more modern and clean way,

In T7995#161249, @Universal_Omega wrote:

In T7995#161248, @Dmehus wrote:

In T7995#161247, @Universal_Omega wrote:

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

Yeah, was planning on waiting at a few more days at least. But the fix in that task, is also an issue in the script so isn't necessarily a blocker. That is actually what made me think of this, as the fix would need to be added to the script if we are keeping it as well.

Okay, sounds good. :)

I know it's not a blocker, I meant just in terms of keeping the script's code in case we need to import some of it into the extension.

All of the script code is already in the extension (implemented in a more modern and clean way though).

But not all the extension code is in the script.

In T7995#161248, @Dmehus wrote:

In T7995#161247, @Universal_Omega wrote:

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

Yeah, was planning on waiting at a few more days at least. But the fix in that task, is also an issue in the script so isn't necessarily a blocker. That is actually what made me think of this, as the fix would need to be added to the script if we are keeping it as well.

Okay, sounds good. :)

I know it's not a blocker, I meant just in terms of keeping the script's code in case we need to import some of it into the extension.

In T7995#161247, @Universal_Omega wrote:

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

Yeah, was planning on waiting at a few more days at least. But the fix in that task, is also an issue in the script so isn't necessarily a blocker. That is actually what made me think of this, as the fix would need to be added to the script if we are keeping it as well.

In T7995#161243, @Dmehus wrote:

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

In T7992#161217, @Universal_Omega wrote:

This task can probably be made public, I don't think it's a true security issue.

I'm okay with this, but let's hold off until you, RhinosF1, or Reception123 have tested and deployed your fix in T7992.

This task can probably be made public, I don't think it's a true security issue.

In T7992#161178, @Universal_Omega wrote:

In T7992#161177, @Dmehus wrote:

In T7992#161176, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/20 - although I'm not certain it will work, and testing RemovePII is quite difficult (especially when needing to test CU which sysadmins don't have access to nor really should, and don't know if it's a good idea to add just for testing). I don't think it'll cause it to error though.

Technically, you could add checkuser and checkuser-log permissions temporarily to sysadmin and test it on a test account, if you needed it, ideally linking to the Phabricator ticket in your log summary.

Yeah. Another thing for me personally is that I'm currently mobile until September 15th, so someone else will likely need to test or at least someone else deploy to test3 for me to test from there.

In T7992#161177, @Dmehus wrote:

In T7992#161176, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/20 - although I'm not certain it will work, and testing RemovePII is quite difficult (especially when needing to test CU which sysadmins don't have access to nor really should, and don't know if it's a good idea to add just for testing). I don't think it'll cause it to error though.

Technically, you could add checkuser and checkuser-log permissions temporarily to sysadmin and test it on a test account, if you needed it, ideally linking to the Phabricator ticket in your log summary.

In T7992#161176, @Universal_Omega wrote:

https://github.com/miraheze/RemovePII/pull/20 - although I'm not certain it will work, and testing RemovePII is quite difficult (especially when needing to test CU which sysadmins don't have access to nor really should, and don't know if it's a good idea to add just for testing). I don't think it'll cause it to error though.

https://github.com/miraheze/RemovePII/pull/20 - although I'm not certain it will work, and testing RemovePII is quite difficult (especially when needing to test CU which sysadmins don't have access to nor really should, and don't know if it's a good idea to add just for testing). I don't think it'll cause it to error though.

In T7992#161168, @RhinosF1 wrote:

It looks based on https://github.com/miraheze/RemovePII/blob/master/includes/RemovePIIJob.php#L80 that we should actually be checking https://github.com/wikimedia/mediawiki-extensions-CheckUser/blob/master/cu_log.sql#L25

In T7992#161173, @RhinosF1 wrote:

@Dmehus: I agree it's a bug. Just pointing out that it's simply the log retained.

@Dmehus: I agree it's a bug. Just pointing out that it's simply the log retained.

In T7992#161169, @RhinosF1 wrote:

@Dmehus: Looking at it, it's only the log entry remaining. There should not be any data.

Oh, if it doesn't work with the extension the script doesn't either. RhinosF1 is right, the way its done now removes acting user not target user it seems.

It should be first renamed, once the rename from RemovePII is done, as technically it is just the user ID that is being removed from database, not username, so as long as rename for user is done first, then it should be removing it from checkuser.

@Dmehus: Looking at it, it's only the log entry remaining. There should not be any data.

It looks based on https://github.com/miraheze/RemovePII/blob/master/includes/RemovePIIJob.php#L80 that we should actually be checking https://github.com/wikimedia/mediawiki-extensions-CheckUser/blob/master/cu_log.sql#L25

• T7942: [ManageWiki] Create better CI for MediaWiki standards and security
• T7943: [CreateWiki] Create better CI for MediaWiki standards and security
• T7944: [MatomoAnalytics] Create better CI for MediaWiki standards and security
• T7945: [GlobalNewFiles] Create better CI for MediaWiki standards and security
• T7946: [RemovePII] Create better CI for MediaWiki standards and security
• T7947: [DataDump] Create better CI for MediaWiki standards and security
• T7948: [RottenLinks] Create better CI for MediaWiki standards and security
• T7949: [IncidentReporting] Create better CI for MediaWiki standards and security
• T7950: [WikiDiscover] Create better CI for MediaWiki standards and security

In T7939#160072, @John wrote:

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

9 different software components = 9 different tasks surely? They just good task management and makes things easily trackable and measurable.

It's probably better to be tracking things separately and have subtasks for each extension

In T7939#160067, @RhinosF1 wrote:

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

In T7939#160062, @John wrote:

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

It's one end objective that all Miraheze maintained extensions have mediawiki-standard CI

One task - one end objective is a standard purpose. Why do we have a task for 9 separate objectives?

I've extended the above mentioned PR to now also include phan.

https://github.com/miraheze/ManageWiki/pull/297 does this for ManageWiki, implementing eslint, stylelint, and phpcs. It also will make GitHub Actions automatically commit formatting fixes, when possible.