> On 3 May 2018, at 12:27, Ecaterina Moraru (Valica) <[email protected]> wrote: > > It would be interesting to have an Administration configuration to ask if > extension customization are allowed or not: > - for advanced developers that want total control of their instance and > create a custom one, they would put YES and do the upgrades on their own;
I’m fine with simple/advanced user but Thomas mentioned that it’s hard/dangerous to do so I’m not sure we should focus on that one FTM. > - (2a) while for Cloud/MyXWiki it would be on NO, using the applications as > they are and only manage the content. Note that it’s not just for Cloud/MyXWiki but any sane admin might want that on the xwiki instance he/she administers to forbid users from changing extension pages because he/she’ll be the one doing the upgrade and doesn’t any bad surprise to upgrade! It’s actually a sane default and the more I think about it and the more I think it should be the default (and allow admins to turn page extension editing on the first time they really need it). Thanks -Vincent > > On Thu, May 3, 2018 at 1:20 PM, Vincent Massol <[email protected]> wrote: > >> >>> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <[email protected]> >> wrote: >>> >>> How I see this problem for extension technical pages: >>> - users -> EDIT right forced false. They don't see the "Edit" button, so >>> they are not tempted to edit. >>> - devs -> WARN. They should be able to modify the pages, but on their own >>> expense. >>> - admins -> WARN. They should be able to control everything, but be aware >>> of the risks. >> >> You’re forgetting the the hosting/easy upgrade use case ;) >> >> Thanks >> -Vincent >> >>> >>> From what I see the above goes into 1b or 3. The only difference is if we >>> should force or not the developers to be admins and also be advanced >> users, >>> which in practice it usually happens. >>> >>> Simpler visualization of the proposal, where -ED=(EDIT right to DENY) and >>> W=(Warning): >>> >>> | Users | Admins | >>> |Basic|Advanced|Basic|Advanced| >>> 0 | W | W | W | W | >>> 1a| -ED | W | -ED | | >>> 1b| -ED | W | W | W | >>> 2a| -ED | -ED | -ED | -ED | >>> 2b| -ED | -ED | W | W | >>> 3 | -ED | -ED | -ED | W | >>> >>> Thanks, >>> Caty >>> >>> >>> >>> On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne < >> [email protected]> >>> wrote: >>> >>>> 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 >>>> >> >>
