https://bugzilla.wikimedia.org/show_bug.cgi?id=69380
--- Comment #18 from Tim Starling <[email protected]> --- (In reply to Tyler Romeo from comment #4) > 2) It makes certain workflows (as mentioned in gerrit) impossible entirely. Sorry, I read the Gerrit comments but didn't see any description of any actual workflow. All I could find was a vague suggestion of "what if someone wants to delete but can't edit", but without any explanation of why such a structure would be useful. If I am missing something, maybe you can point it out? (In reply to rschen7754.wiki from comment #2) > This had the effect of making it impossible for global sysops to delete > anything on login.wikimedia.org, since they cannot edit those pages but > loginwiki is in the GS set. I think that is an improvement. Global sysops should not be able to delete pages on login.wikimedia.org if they can't even edit them. (In reply to Nemo from comment #13) > Do we also have specific existing use cases/workflows to consider? > Investigators could start by looking into how the "eliminator" group is used > on ckb.wiki, ja.wiki and pt.wiki, as well as ru.wiki's "closer" group and > frwiktionary's "move-rootuserpages": none of these groups appears to have > editinterface, editprotected or similar. Please add cc's and notify those > wikis as appropriate. Thanks Nemo, that is helpful. The "eliminator" and "closer" groups are relatively unprivileged groups, able to delete pages but not able to do potentially dangerous site-wide things like edit the MediaWiki namespace. I think it makes perfect sense to prevent such users from deleting superprotected pages -- or indeed, any MediaWiki namespace page. It seems to me that there are three options: 1. Keep the patch, require edit permissions in order to move. There are plenty of precedents for linking of rights in this way in core, so it's not as inelegant as Tyler makes out. 2. Make the delete action be a separate restriction type, so that pages can be delete-protected in the same way as they can be move-protected There are already four actions treated in this way: edit, create, move and upload, so on the face of it, adding a fifth doesn't seem too terrible. The number of boxes on the protection form is currently about 2 or 3, if you include Pending Changes which also adds a box here, and that number would increase by 1. The interface is not too terrible with the "unlock further protection options" box unchecked -- the delete protection level would implicitly be the same as the edit protection level. 3. Do not show a delete protection UI, but implicitly treat edit protection as equivalent to delete protection. Edit protection would be conflated, rather than edit rights. If you have to conflate two things, then I suppose it makes sense to choose narrower things to conflate, and protection is narrower than rights. A careful implementation of this option would allow future migration to option 2, if that is necessary. Broadly: option 1 has a convenient UI and has beneficial side-effects, such as preventing "eliminators" from deleting MediaWiki namespace pages when they don't have editinterface rights. Its disadvantage is its inflexibility and lack of a migration path towards more fine-grained controls. Option 2 has an ugly UI but an elegant backend. Option 3 has a convenient UI and a good migration path, but the side-effects of option 1 may have to be implemented in some other way. I don't think merely reverting the patch is a suitable long-term option -- we don't want to incentivize deletion of super-protected pages, since history is lost, and pages with missing JS may be cached into Varnish before the page is recreated. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
