> On 3 May 2018, at 12:11, Ecaterina Moraru (Valica) <vali...@gmail.com> 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 <thomas.morta...@xwiki.com> > 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 <vinc...@massol.net> wrote: >>> Hi Thomas, >>> >>>> On 30 Apr 2018, at 14:29, Thomas Mortagne <thomas.morta...@xwiki.com> >> 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 >>
