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; - (2a) while for Cloud/MyXWiki it would be on NO, using the applications as they are and only manage the content.
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 > >> > >
