3 May
2018
3 May
'18
3:09 p.m.
On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
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.
On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
provide
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 <
thomas.mortagne(a)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 <vincent(a)massol.net>
wrote:
> Hi
Thomas,
>
>> On 30 Apr 2018, at 14:29, Thomas Mortagne <thomas.mortagne(a)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 > 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