Forums / Setup & design / Again: Order of role-assignment

Again: Order of role-assignment

Author Message

Tim Krah

Wednesday 27 October 2004 12:37:35 am

Hi comunity!

I would like to repost my Topic from 16 December 2003, because there were no hints and the problem still exists for me:

I have many different user-groups, each having assigned different roles. If an user exists in more than one group, which role-permissions will be assigned to that user? The 'most strict' permissions supersede the 'looser' permissions? Or will the second role-permission-set overwrite the first role-permission-set, so the order in which the roles will be asigned to a user is important?

Frederik Holljen

Wednesday 27 October 2004 12:43:11 am

You will get the loosest permissions possible. Order does not matter.

Tim Krah

Wednesday 27 October 2004 1:11:03 am

Good to know, thanks for the quick reply!

By the way: is there an in-depth documentation on the role-system?

Frederik Holljen

Wednesday 27 October 2004 1:22:14 am

Documentation will be a priority in the 3.6 release cycle. At the moment we do not have an in depth explanation of the role system.

Paul Borgermans

Wednesday 27 October 2004 2:13:23 am

 You will get the loosest permissions possible. Order does not matter.

Ok that the order does not matter, but loosest permissions?
That's not what I find (3.4-2):

suppose this situation

role (1)   content create & edit class(x) 
           content read class(x) owner(self)

role (2)   content read class(any) subtree(where the objects of class(x) live)
----------------------
group (a) has only role (1)
group (b) has roles (1) and (2)

Wouldn't you expect that group(b) can read all class(x) objects? It isn't :-( , they can oly read their own objects

When i use

role (1)   content create & edit class(x) 
           content read class(x) owner(self)

role (2)   content read class(x) subtree(where the objects of class(x) live)

Than it works, as i expect for group (b)

Is this intentional or a bug?

regards

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Jan Borsodi

Wednesday 27 October 2004 5:02:49 am

I am not able to reproduce this, I created the example you showed using 3.4 and it worked as it should.
I tested with a different policy order by adding in a array_reverse in the code, still no change in behaviour.

Also looking trough the code I cannot see how this could fail.
It checks one policy at a time, if all limitations of the policy is allowed then the operation is allowed.
If one of the limitations of a policy is not allowed it considers the whole policy as not being allowed.

Could you please retry your example.

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Paul Borgermans

Wednesday 27 October 2004 5:27:45 am

Yes Amos,

You are right. I found a section limitation (by not including it in an explicit section list with explicit classes) in another role that intervened with this one. Sorry, should have looked more profoundly before posting this.

Thanks for clarifying, I'll look through the code in detail as a kind of constructive self-punishment ;-)

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans