10 Jun
2010
10 Jun
'10
10:17 a.m.
2010-06-09 11:57, Sergiu Dumitriu skrev:
+1.
On 05/27/2010 10:26 AM, Denis Gervalle wrote:
I think it would be preferable with a well defined priority order:
1. Lower level in hierarchy (main wiki -> virtual wiki -> space [->
space ...] -> document) beats higher level
2. User right beats group right
3. Deny beats allow
I don't think that this is sufficient, though, since you would need to
deny all on wiki to give exclusive allow to group A on space X. A
group priority would also be desired:
1. Lower level in hierarchy beats higher level
2. User right beats group right
3. Higher group priority beats lower group priority
4. Deny beats allow
So XWikiAllGroup should have the lowest priority, other groups should
have higher priority, and subgroups should have higher priority than
the parent group. Then you'd just set deny for XWikiAllGroup/allow for
group A on space X, and it would work as expected without any side
effects.
If the behaviour is changed, the backward compliancy issue is quite
hard, as Sergiu points out. I can see two possibilities:
1. Provide two implementations. Use new implementation on newly
installed wikis, and the old one when upgrading old wikis.
2. Provide a script that walks the wiki and converts the rights to
equivalent ones in the new system.
The second option might not be feasable, as it seems non-trivial to
formalize the current behavior. A compromise is to make a script that
makes a best-effort guess at defining group priorities and right mappings
that will have to be manually inspected.
/Andreas
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
>