On Thu, May 3, 2018 at 1:32 PM, Vincent Massol <[email protected]> wrote:
> > > > 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! > They can do this already with access rights. The problem is that: * The Extension Manager doesn't have an UI to list the pages belonging to an installed XAR extension * The Admin doesn't always know which page from the extension XAR should be protected (which is code and which is demo content) We could probably add a step at the end of XAR extension install to allow the administrator to configure the extension/application access rights. This step could also be an administration section under User & Rights, e.g "Applications" where we show a tree with installed XAR extensions at the top and their pages below, allowing the administrator to configure the access rights. The issue is choosing/providing a default. The default could be based on the XAR page type, e.g. after a XAR extension is installed a script set edit right to allow for admin group based on the page type. > > 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 > >>>> > >> > >> > >
