In T9195#209617, @OrangeStar wrote:

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

A dialogue box if the group contains managewiki rights is a rather easy solution to implement as all the logic would just be checking the group rights that are already exposed for the rights selection pages.

In T10230#206302, @John wrote:

But it would still generate a new workflow that eventually someone would go "so this happens and we should fix it" whereby legitimate deletions are needed. Plus that then raises a question of - should we keep a broken system we can fix than over fix and break something that works and in theory, isn't a problem that needs fixing?

We should work to fix problems - not create problems by breaking what works and is unique.

In T10230#206301, @Agent_Isai wrote:

In T10230#206299, @John wrote:

Personally, I think we should just provide a warning rather than restrict the ability entirely - a user can correctly reconfigure the wiki ecosystem and this would then generate a new type of workload of requesting stewards correctly delete a bureaucrat or sysop group thereby changing the problem, not fixing it.

Even better would be to make it so the user can't delete a user group if it would remove *their* access to ManageWiki - this would not be group specific and would solve the problem above while also resolving the core issue.

A Steward would only delete the group if a replacement group exists with ManageWiki/equivalent rights assigned. I discussed a similar proposal with CosmicAlpha who said it would be harder to implement hence why this was suggested as an alternative. If anyone wants to give it a try then that'd be most welcome.

In T10230#206301, @Agent_Isai wrote:

In T10230#206299, @John wrote:

Personally, I think we should just provide a warning rather than restrict the ability entirely - a user can correctly reconfigure the wiki ecosystem and this would then generate a new type of workload of requesting stewards correctly delete a bureaucrat or sysop group thereby changing the problem, not fixing it.

Even better would be to make it so the user can't delete a user group if it would remove *their* access to ManageWiki - this would not be group specific and would solve the problem above while also resolving the core issue.

A Steward would only delete the group if an alternative exists for it. I discussed this with CosmicAlpha who said it would be harder to implement hence why this was suggested as an alternative instead. If anyone wants to give it a try then that'd be most welcome.

In T10230#206299, @John wrote:

Personally, I think we should just provide a warning rather than restrict the ability entirely - a user can correctly reconfigure the wiki ecosystem and this would then generate a new type of workload of requesting stewards correctly delete a bureaucrat or sysop group thereby changing the problem, not fixing it.

Even better would be to make it so the user can't delete a user group if it would remove *their* access to ManageWiki - this would not be group specific and would solve the problem above while also resolving the core issue.

In T10230#206299, @John wrote:

Personally, I think we should just provide a warning rather than restrict the ability entirely - a user can correctly reconfigure the wiki ecosystem and this would then generate a new type of workload of requesting stewards correctly delete a bureaucrat or sysop group thereby changing the problem, not fixing it.

Even better would be to make it so the user can't delete a user group if it would remove *their* access to ManageWiki - this would not be group specific and would solve the problem above while also resolving the core issue.

Personally, I think we should just provide a warning rather than restrict the ability entirely - a user can correctly reconfigure the wiki ecosystem and this would then generate a new type of workload of requesting stewards correctly delete a bureaucrat or sysop group thereby changing the problem, not fixing it.

In T10109#203701, @labster wrote:

Ah, okay. It was so quiet in the other tickets about fixing the current issue that I assumed nothing had been done. Closing as resolved.

Ah, okay. It was so quiet in the other tickets about fixing the current issue that I assumed nothing had been done. Closing as resolved.

I already fixed this in ManageWiki to not happen again.

This should now be fixed.

Should now be resolved (this was not related to the other patch, this was something else)

Per the above.

Unfortunately it can not be done less than 1 day in ManageWiki, changing this functionality in ManageWiki would require having the input be in seconds which would mess up all current values for all wikis, we can not do this outside ManageWiki either due to the way ManageWiki works. Apologies for the inconvenience.

In T9736#196631, @Vlad26t wrote:

In T9736#196595, @Void wrote:

The writeapi permission is also a required component for certain features and extensions, some of which may not be immediately obvious. This includes VisualEditor and DiscussionTools, though other extensions such as Comments may also not work without that permission. That being said, it's hard to determine the entirety of what may be affected given that some of these extensions don't list the requirement.

Limitation of the writeapi permission could prevent vandalism through the API—extensions such as VisualEditor and DiscussionTools also may be target. If there is needed to mitigate the results of that, the writeapi permission can be temporarily removed from some user groups, but the edition of pages via the "edit" tab to be still available to everyone.

In T9736#196595, @Void wrote:

The writeapi permission is also a required component for certain features and extensions, some of which may not be immediately obvious. This includes VisualEditor and DiscussionTools, though other extensions such as Comments may also not work without that permission. That being said, it's hard to determine the entirety of what may be affected given that some of these extensions don't list the requirement.

The writeapi permission is also a required component for certain features and extensions, some of which may not be immediately obvious. This includes VisualEditor and DiscussionTools, though other extensions such as Comments may also not work without that permission. That being said, it's hard to determine the entirety of what may be affected given that some of these extensions don't list the requirement.

In T9736#196580, @Agent_Isai wrote:

This was done on purpose as I understand it was causing far too
many issues by users who revoked it from the user group.

This was done on purpose as I understand it was causing far too
many issues by users who revoked it from the user group.

In T9195#195130, @John wrote:

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

Now fixed.

The upgrade to MediaWiki 1.38 seems to have fixed this issue. I've now removed the wordmark image on the wiki in question.

https://github.com/miraheze/ManageWiki/pull/362 (and a follow-up with https://github.com/miraheze/ManageWiki/commit/4771142) should fix it. That will be deployed tomorrow alongside our 1.38 upgrade. Closing as resolved since while the issue is still present on-wiki, the issue is resolved within ManageWiki.

This should now be fixed. Apologies for the issue.

https://github.com/miraheze/ManageWiki/pull/359 should hopefully fix this. The issue is not as severe as I initially thought since autopromote still is functional, it just gets overriden if group is saved again, since the form defaults for the autopromote groups is incorrect.

I am able to reproduce with 100% reproduction. (Every single time)

Though I am not sure of the details of some Special:ManageWiki/subpage that I did not use, I agree that there should be an improvement.
Some thought:

This is in 1.38 & 1.39

https://phabricator.wikimedia.org/T221535

Multiple webhooks can now be added via ManageWiki.

Stalled on 1.38 being used.

All configuration variables updated, so this is now done, as all instances in the extensions should now be updated.

https://github.com/miraheze/CreateWiki/pull/280 will rename two CreateWiki global configuration variables.

This needs changing in ManageWiki, and CreateWiki to rename configs etc. I'm not bothered by GitHub branches and that's not something I think this task should encompass. I will work on it in ManageWiki and CreateWiki.

Most things are probably upstream

The main one for us is github branches