I was under the impression @Reception123 or @Paladox were dealing with this the other day.

Why does SPF need to approve something anyone in SRE can do of their own volition? If this is such an important issue, you’re creating a slowdown intentionally

“ would require more resources to implement - potentially more than we are able to suitably give.” is a vital thing you did not reply to, the more critical part.

Would not solve problems, and would require more resources to implement - potentially more than we are able to suitably give.

In T5998#117295, @RhinosF1 wrote:

Cc @John as I think ManageWiki uses it so he can confirm but is it not already available?

Still marking as invalid per my original rationale. This would take seconds to do by anyone who wanted to do so as a sysadmin - however I'm not seeing any specific request for action from anyone affected by this issue.

Specific requests should be made for wikis if they want all revisions to be automatically patrolled.

So, resolved then?

I do agree with browser issue. Edge for me persists the session, I’ve been logged in with GitHub for a few weeks now. Chrome however does not persist this to this level for me.

The table needs to structured the same way, so implementing this change means we list the newest unreviewed requests first, not the oldest which is more logical.

In T5965#116720, @Reception123 wrote:

@John What do you think about this? What should be done?

This can be enabled using Special:ManageWiki/extensions

In T5942#116168, @Dmehus wrote:

@John, have you tried logging in with your GitHub account?

I’m unable to reproduce the problem, I stay logged in and have been for months across multiple devices and browsers.

Easy fix, use —wiki otherwise an error is expected.

I've looked in the logs and I can't see any evidence of an exception occurring around the time being reported. Without the "random hash" this is impossible to debug.

Basic plan and potential workflow for the end product shall be;

Unable to reproduce on the wiki

In T5902#115326, @AmandaCath wrote:

I was told by @John before that Phabricator accounts, although they can be renamed, that renaming them after using them would break things.

You need to delete the namespace https://hrfwiki2.miraheze.org/wiki/Special:ManageWiki/namespaces/3000 in order to restore namespace aliasing.

Why is this task still private?

Can we stop warring over tags please? MirahezeMagic isn’t an extension for us, it’s a way to collate scripts we’d want in core. Therefore, this is a generic issue - not an extension issue.

Something not right here, either this isn’t a high priority security issue, or we’re not taking this issue seriously. Can someone please confirm which it is, and do the necessary steps to resolve it as this is way past a reasonable SLA.

I don’t have access currently or time to handle this. Any sysadmin can delete it from the database and any sysadmin can also clean up the mess.

In T5827#113890, @Cocopuff2018 wrote:

Ok can i go ahead and list them here to be deleted? and may i ask why we no longer able to delete them?

You are unable to, a system administrator will need to remove them from the database.

The user group has a blank user right assigned, so this needs to be removed by a system administrator.

Progress? High priority tasks should be resolved as soon as is practically possible, not at a leisurely pace

#3 is fixed, #1 is normal behaviour

This is kind of a moot point to be honesnt, everyone is SRE has the key responsibility to monitor the infrastructure health - this means monitoring alerts too.

So then I/O is the issue. So then workload is the issue.

“ Not every security issue equals UBN.” is plainly wrong. Every security incident needs to be resolved as soon as possible at the highest urgency

In T5762#112399, @Paladox wrote:

@John maybe you have ideas on how to resolve this?

HDD or SSD, a load warning is a warning. It should not be happening.

Upstream Chrome issue

Nothing of relevance then. Points brought up are invalid or common knowledge.

https://github.com/miraheze/ManageWiki/commit/95ce49b53a0729d500b85d961b666f8bb4d239ba Broke it

I don’t know - that’s why I’ve left this task open as I don’t have time 24/7. But the responsibility is on the user so even if I was to decline this, it’s not an issue with the software.

I’m aware. But the setting isn’t incorrect - it’s incomplete by user error - not wrong.

This isn’t an incorrect value, it’s technically correct.

Deletion requests are handled by Stewards