Re: [Hypercontent-users] Resolving conflicting permissions inherited from groups

[Alex V. <al...@bi...>]

Hi,
	The only factor in resolving conflicting but equally specific  
permissions applied to different ancestor groups of a user is depth.   
If the user belongs directly to group A, and also belongs to group C  
that is a subgroup of group B, a permission applied to group A takes  
precedence over one applied to group B for that user because the  
depth of the user from A is less than from B.  If you have  
conflicting permissions on A and C, however, the result is arbitrary,  
as the user is at equal depth from each -  I believe the first  
permission declared in permissions.xml may end up taking precedence,  
but I wouldn't guarantee it!
	So if you want the permissions applied to group:approvers to take  
precedence, create a subgroup of group:authors, e.g. "group:casual- 
authors", and move the user there from group:authors.  This weakens  
the association between the user and the group:authors by increasing  
depth.  The inverse holds true - if you want group:author permissions  
to take precedence for that user, you would place them in subgroup of  
group:approvers, e.g. "group:casual-approvers".
	Keep in mind that group depth is only evaluated after the  
permissions with the most specific targets have been selected, so a  
permission on "/config/**/*.*" always takes precedence over a  
permission on "/**/*.*" regardless of the depth of the user in  
relation to the groups to which those permissions are applied.

Alex

On Sep 10, 2007, at 9:25 PM, tom tom wrote:

> Hi Alex,
>
> How the permissions get overidden, for e.g.
>
> If I give persmission to build as an 'Author' and deny
> the permissions to build as an 'Approver' and if
> someone is a author and approver, what will happen,
> will the author permissions get overidden by approver
> rights.
>
> Can you explain, how does this permission model works
> with respect to the groups
>
>
> Thanks
>
>
>
>
> --- Alex Vigdor <al...@bi...> wrote:
>
>> The permissions approach should work - it works for
>> me!  Make sure to
>> test as a user who is not in group:admin and also
>> not in the
>> publisher group.
>>
>> Alex
>>
>> On Sep 3, 2007, at 8:03 PM, tom tom wrote:
>>
>>> Hi,
>>>
>>> If there is a business requirement to remove the
>> build
>>> and build All links from the workflow screen for
>>> approvers what is the best way to do, I thought we
>> can
>>> do it via permissions.xml as follows but it still
>>> shows the links, is there any declarative way to
>> do
>>> this?
>>>
>>> <permission activity="build" denied="true"
>>> principal="group:approvers" target="/**/"/>
>>> <permission activity="build" denied="true"
>>> principal="group:approvers" target="/**/*.*"/>
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>
> ______________________________________________________________________
>>
>>> ______________
>>> Moody friends. Drama queens. Your life? Nope! -
>> their life, your
>>> story. Play Sims Stories at Yahoo! Games.
>>> http://sims.yahoo.com/
>>>
>>
>>
>>
> ---------------------------------------------------------------------- 
> ---
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?
>> Stop.
>> Now Search log events and configuration files using
>> AJAX and a browser.
>> Download your FREE copy of Splunk now >>
>> http://get.splunk.com/
>> _______________________________________________
>> Hypercontent-users mailing list
>> Hyp...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/hypercontent-users
>>
>
>
>
>
> ______________________________________________________________________ 
> ______________
> Need a vacation? Get great deals
> to amazing places on Yahoo! Travel.
> http://travel.yahoo.com/
>