On Wed, Jun 9, 2010 at 12:57, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 05/27/2010 10:26 AM, Denis Gervalle wrote:
On Thu, May 27, 2010 at 09:57, Ecaterina
Valica<valicac(a)gmail.com>
wrote:
> Hi,
>
> I want to talk a bit about:
>
>> The inheritance is a little bit particular, since allowing a given
right
at
lower level, will deny that same right for
anybody else even if this
right
is allowed at a higher level.
I want to know how hard this would be to be changed.
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
> Another question is why this has been done in the first place? Can
someone
give a
valid use case when this is more productive than other ways.
I really do not know, and I am curious as well.
It was done because the deny right is stronger than the allow right. How
can I say that for space X only group A has view right, and nobody else?
Attempt 1. Deny to Guest and All, allow to A. Oups, doesn't work, since
everybody in A is also in All, and deny is stronger, so everyone is
denied...
IMO, RegisteredUsers is a special case. Imagine RegisteredUsers as a Wiki,
and GroupA as a Space; and have the same level of appliance for groups
(page-space-wiki, where space rights override wiki rights).
So if I deny All and allow A, semantically A will have allow, because the
tie will be broken by level. Just a thought.
Caty
Attempt 2. Hm, how could this be done? Denying to everybody is not an
option... So, allow the view right to A, and automagically everybody
else is denied. Great, XWiki really rocks!
This is not a very valid use case, but more like a necessity. When
designing the current rights mechanism, a lot of not-entirely-compatible
use cases had to be balanced, and the outcome doesn't cleanly satisfy
all use cases, but it tries to make each scenario possible one way or
another.
> It is very confusing and users need to do additional steps in order to
give
the
rights they want.
I completely agree, this is poor.
I think is a problem of how the Groups are perceived. Only as a rights
mechanism or as a semantically grouping.
We should not decide this, since groups maybe synchronized from external
system (ie LDAP), imposing groups for rights is not correct. By the way,
groups may contains groups, but I am almost sure that this will work
properly in practice.
> If we use groups just to give rights than the current implementation is
> usable. But if you have groups, like Tech team, Design team, Marketing,
> Happy team ... etc in order to classify our users in other ways beside
> rights management, giving permission to a user is breaking all the
> inheritance from upper levels.
>
> Example:
> Group A(Managers) has View (default allowed) at wiki level - this means
> that
> they should be allowed to view all the pages in the wiki.
> Group B(Tech Team) has View (explicitly denied) at spaceX level - this
> means
> they shouldn't be allowed to view this space.
>
> But I have a person (the managerX) in Group B that is supposed to see
the
> info in spaceX level. So the first logical
move would be to give him
allow
> at space level (having in mind that space
rights are stronger that wiki
> rights and the view right has been overriden). But, if I give managerX
view
> right, all the other groups (incluing
Managers) will be denied for
spaceX
> level. This means I need to know that and
"repair" again all the rights
I
ALREADY
set at the higher level.
This behavior is not logical for me.
It is not logical for me and I imagine many others !
>
> A solution would be to take out managerX form Group B and leave it just
in
> Managers group. Yes, this way my problem is
solved, but this means
Groups
> are only used for Rights purposes. Group B
(Tech Team) is no longer
> semantically compact and I can't further give this group compact tasks,
> etc.
>
> Please tell if is a way to change this behavior and please have in mind
> XWiki 3.0, where Groups are going beyond rights management and they
should
be seen
as collaboration mechanisms (which need to be semantical).
IMO, XWiki 3.0 should have a complete rework of the right service
implementation, and breaks with the past.
Since this will cause many migration issue, I am not in favor of
progressive
changes, and I would prefer to see a big single
change that fix this, and
also the current discussion on script rights.
+1.
Denis
Rights should be inherited from upper level and should affect only the
> user/group where a change is made, not make some complicated
implications
> at
> other levels and groups.
>
> Thanks,
> Caty
--
Sergiu Dumitriu
<http://purl.org/net/sergiu/>