Sat, Nov 21
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?
Fri, Nov 20
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.
Sat, Nov 7
Oct 8 2020
Sep 22 2020
Sep 20 2020
Sep 9 2020
Aug 30 2020
Aug 29 2020
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/
Aug 28 2020
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.
Aug 27 2020
I have submitted a patch for $wgRestrictionLevels
Aug 24 2020
Whatever you think is best.
Aug 23 2020
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?
Aug 20 2020
Rate limiting implemented on cache proxies, monitoring now.
Aug 19 2020
Here the alerts go again
Aug 18 2020
Aug 3 2020
Aug 2 2020
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.
Aug 1 2020
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.
Jul 31 2020
I learned a lot via DM about the not-quite-outage. The most interesting theory I've heard (and I *think* that @RhinosF1 gets credit for this) is that the job for updating global user pages is dying for some reason. However, it could be that something other process (which is trying to be helpful) is killing those processes.
my runJobs script was accidently on mw7 but load looks fine so I'm leaving it there to avoid restarting it. I'll move if it causes an issue.