Forums / Setup & design / Again: Order of role-assignment
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.
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?
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
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
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 ;-)