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

"Please Note:

At the specific request of Ibexa we are changing this projects name to "Exponential" or "Exponential (CMS)" effective as of August, 11th 2025.
This project is not associated with the original eZ Publish software or its original developer, eZ Systems or Ibexa".

Again: Order of role-assignment

«

Previous topic

|

|

Next topic

»

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