https://bugzilla.wikimedia.org/show_bug.cgi?id=69380
--- Comment #22 from Tyler Romeo <[email protected]> --- (In reply to Tim Starling from comment #18) > (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? Why are you asking for a workflow when you acknowledged one later in your same comment? (In reply to Tim Starling from comment #18) > (In reply to Nemo from comment #13) > 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. Precedent does not make it an elegant solution. Just because bad examples exist does not mean we should be adding more of them. One of the purposes of RBAC is the maximal customization. Since the permissions are atomic, the administrator can define any user group he/she wants. Imposing our own permission dependencies where not technically necessary imposes a restriction that would not otherwise exist. I do not see the advantage of restricting administrators' customization abilities and making the permissions system more complicated for absolutely no reason at all, even if a practical workflow has not been demonstrated. > 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. I think that, moving forward, this would be the best option. However, it is a lot more complicated since we have to change the UI, the protection backend, etc. > 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. ^this exactly. I like this option, especially with the option of a future migration to option 2 if we decide. -- 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
