2010-06-09 11:57, Sergiu Dumitriu skrev:
> On 05/27/2010 10:26 AM, Denis Gervalle wrote:
>
>> On Thu, May 27, 2010 at 09:57, Ecaterina Valica<[email protected]> 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...
>
> 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.
>
>
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
>>
>>> 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
>>>
>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
