Page MenuHomeMiraheze

Decide what to do with the removePII MirahezeMagic maintenance script
Closed, ResolvedPublic

Description

We should decide whether to delete the maintenance script, or later move it to the RemovePII extension as an alternative way to delete data. It actually currently in its current state removes much less information then the extension, and is somewhat difficult to maintain both the extension's job and the maintenance script. Simply deleting it may be best, as it is obsolete now with the RemovePII extension. It's also less reliable then the extension as it requires a locally attached account to meta, and doesn't delete all the information the extension does. Since the extension has been performing sufficiently removing it at this point seems like an okay action.

Assigned to myself as whatever action is decided upon I will work on doing. It's simple to complete if we are just deleting it but to move it will take more time as it will need rewrote to be up-to-date in MediaWiki standards, and to delete the same information as the RemovePII job. Regardless I don't think we should keep it in MirahezeMagic.

Event Timeline

Universal_Omega created this task.
Universal_Omega moved this task from Backlog to Features on the RemovePII board.
Universal_Omega moved this task from Unsorted to Goals on the Universal Omega board.
Universal_Omega lowered the priority of this task from Normal to Low.Sep 7 2021, 02:08

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

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.

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.

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.

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,

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.

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.