On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica) <[email protected]> wrote: > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <[email protected]> > wrote: > >> By "users" and "devs" you mean "basic" and advanced, right ? >> > > It would be ideal if we could just say it's just basic or advanced. I meant > more from a purpose point of view. > "Devs" can be defined as advanced users or advanced admins, but the main > differentiator is their clear intention to modify and create apps.
Sure but there is no standard way to indicate that someone is a "dev" in XWiki so I will need more details :) IMO the closest we have right now is "advanced" so that' what I listed. > > > >> >> On Thu, May 3, 2018 at 12:11 PM, 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. >> > >> > 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 >> >> >> >> >> >> -- >> Thomas Mortagne >> -- Thomas Mortagne
