9 Jun
2010
9 Jun
'10
11:57 a.m.
On 05/27/2010 10:26 AM, Denis Gervalle wrote:
+1.
On Thu, May 27, 2010 at 09:57, Ecaterina
Valica<valicac(a)gmail.com> wrote:
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...
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.
Hi,
I want to talk a bit about:
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
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.
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 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. 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/