This bug is still in effect but I figured out an easy fix...

I'm going to liaise with @Owen to see if we can achieve this before this goal period ends. Based on last progress update from him, I think it's just a web API and then extension implementation left?

After considering this task, I think it should be declined. The reasons for this are that I can't really see a real case where this user setting would be useful.

Seems resolved.

Per a response I received from @John, $wgRevokePermissions will not be added to ManageWiki. As for $wgRestrictionLevels it is still possible but will require a little bit more work to do.

Another update on this: I have decided to go ahead with adding $wgRevokePermissions to ManageWikiPermissions. It adds another "Revoked Permissions" tab to ManageWikiPermissions, that modifies the $wgRevokePermissions array. It is currently awaiting review and testing to verify it is working. https://github.com/miraheze/ManageWiki/pull/179/

In T4943#99774, @RhinosF1 wrote:

I don't think we support these types of config variables in ManageWiki ?

Alright, an update on this: $wgRestrictionLevels may not be possible to add to ManageWiki, I was able to add an array to ManageWiki, but I completely read the documentation for it wrongly. I thought the array was for usergroups, and as it turns out, it is for userrights. I missed this part:

$wgRestrictionLevels holds a list of user permissions/rights, not user groups.

I have submitted a patch for $wgRestrictionLevels
https://github.com/miraheze/mw-config/pull/3215

In T5501#119007, @Jidanni wrote:

Whatever you think is best.

Whatever you think is best.

I believe this is a good idea. Do you think the header title ("Manage this wiki's permissions") to append "(groupname)" to it? Another option is add a subtitle which displays the group name. That should not be super hard to achieve. Is this what you have in mind?

Rate limiting implemented on cache proxies, monitoring now.

Here the alerts go again

It would also be a good way to avoid issues like T5827.

Adding subscriber per request on Discord

Latest stable version from 2013. No updates to the code whatsoever since 2018. Unmaintained.

The issue described here has now been resolved and the backlog has been cleared. As an actionable T5994 has been created and therefore the discussion for how to prevent this from happening again can be taken over there.

@RobLa: I'll talk to @Southparkfan about how we don't get here again but it looks to be just a case of bringing the backlog under control now.