Right I actually forgot to list one possibility in the first mail: 0) Warning for everyone (so what we have in 10.3)
On Wed, May 2, 2018 at 6:56 PM, Vincent Massol <[email protected]> wrote: > Hi Thomas, > >> On 30 Apr 2018, at 14:29, Thomas Mortagne <[email protected]> wrote: >> >> Hi xwikiers, >> >> In 10.3 we introduced a warning to discourage users from editing >> extension pages (unless the extension indicate it's OK to edit it). >> >> This was a first version to have something in 10.3 but the initial >> (vague) plan (for 10.4 this time) base on previous discussions was: >> >> * EDIT right forced false for basic users >> * still a warning for advanced users >> * various options to change that (EDIT right forced false for >> everyone, warning for everyone, etc.) > > Note: I haven’t read what’s below yet (looks complex ;)). > > From a functional POV the minimal needs IMO are: > > * The warning you’ve already implemented is good as the default > * We also need to take the hosting use case, where some company provide xwiki > hosting and they want to prevent users (including admins, for superadmin it’s > ok) from editing extension pages so that they can perform xwiki upgrades > automatically with no conflicts. > > Ofc if we can support Advanced user vs Simple user use cases (i.e. forbid > simple user from editing extension pages) that’s nice too but less important > IMO. > > Thanks > -Vincent > >> That was before I actually look at what we can do with our security system :) >> >> Turns out that it's not a huge fan of dynamic criteria like >> "basic/advanced user", it's still possible but will require a big of >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a >> protected document would not exactly be straightforward. >> >> Before starting big stuff I would like to discuss in more details what >> we want in the end. >> >> In this mail I would like to focus on default behavior and we can talk >> about which options we need to provide in another one: >> >> Note: in all of theses superdamin still have the right to edit >> everything (with a warning). >> >> 1) Basic/advanced based >> >> 1.a) >> >> Forced EDIT right to DENY for basic users. >> Edit warning for advanced users. >> Forced EDIT right to DENY for basic admins (we overwrite the ADMIN >> implied rights logic) >> >> 1.b) >> >> Forced EDIT right to DENY for basic users. >> Edit warning for advanced users. >> Edit warning for admins (they get EDIT trough ADMIN right). >> >> 2) Admin right based >> >> 2.a) >> >> Forced EDIT right to DENY for everyone >> Even admins >> >> 2.b) >> >> Forced EDIT right to DENY for everyone >> Edit warning for admins (they get EDIT trough ADMIN right). >> >> 3) Both >> >> Warning if you are both advanced user and have ADMIN right >> Forced EDIT right to DENY for everyone else >> >> WDYT ? >> >> The initial plan was 1.a in my mind but I'm still hesitating. 2.b is >> by far the easiest to implement and probably good enough but not sure >> having ADMIN right is the right criteria to be allowed to force edit >> of protected pages since it's not about security and more about >> knowledge. >> >> I'm -1 for 2.a) as a default. It's way too harsh for the product (but >> I can understand it as an option in a cloud offering for example). >> It's quite young and we will most probably forget to indicate that >> some pages are OK for edit for a little while, plus there is Contrib >> extensions which will probably never get configured properly because >> not really maintained anymore but still used. >> >> In term of refactoring/hacking to the current design the most >> dangerous option is working around the imply link between ADMIN and >> EDIT rights. The right system was not really designed for >> basic/advanced criteria use case but it's OK. >> >> Thanks, >> -- >> Thomas Mortagne > -- Thomas Mortagne
