Wednesday 10 December 2003 9:33:11 am

Hm, I'm sure there is some docu somewhere here, but i couldn't find it right now.
I think, there are some pages in the official ez3-presentations: http://ez.no/developer/ez_publish_3 in the box on the right, at the bottom.

Quick rundown:
Users are used to .... have users ;) Well, for personification and permission stuff, for example.
As long as you are not logged in, ez3 uses a special user called "Anonymous". Sounds strange, but has some nice advantages ;)
You can group in user groups for better handling and for simpliyfing the permission system. You can cascade (build "tree") with user groups, but i think, there is an open bug, when you want to assing permissions to user groups and they are cascaded.
Until now, we didn't talk about permission. Permissions are done with roles.
A role hold one or more "policies". They define, if a user can login at all, what content he can read or write or edit or delete etc. etc.
Your role has some of these "policies" and with this, you create a "profile". This should be task-based, so when you define a role, you ask yourself: What rights (permissions) does a person need, when he needs to accomplish a Task "A"? Define a Role "A".
What does he need to do "B"? Define a Role "B".

Then, you assigne the role to individual users or user groups.

The permissions, that are valid for a user, are a summary of the permissions of all roles he has assigned and all roles, that "his" user groups have assigned.

When you don't assign a role with some permissions to a user (group), they have no rights.

Note: Take care of the role and User "Anonymous", who usually can read some public part (section) of the site.

One more:
For some functions (like "read content") you can define in some .ini file (site.ini?), that they do not need any rights. Those will be available to everyone, bypassing the permission system!
Usually the function "user login" and "user logout" are handled in the .ini
Hope that helps.

Marco
http://www.hyperroad-design.com

Friday 12 December 2003 4:42:27 am

Hi Marco, ez team,

I've additional questions to the role system. It would be fine if one the ez team answers too. I mainly want to know the theory, then I could test it for myself and report bugs :)

Example 1:
I have two roles with different policies.

node tree:
--main
-----subtree 1
--------article
--------user account
-----subtree 2
--------article
--------user account

role:
"registered user" -
-) is allowed to read all content which is in the subtree 1

"editor"
-) is allowed to edit all content which is in the subtree 1
-) is allowed to edit articles which are in the subtree 2

If I create a user and assign both roles to him, is the user allowed to edit AND read content in subtree 1?

Are there "default" dependencies between policies? For example: I give the user only the permission to edit content of class xy. Is he able to "read" the content before / after editing? (Another example: If I give the user only the right to delete content of the class xy is he "automaticly" able to read and edit the content of class xy?)

role "example":
-) read all content in subtree 1
-) edit all content in subtree 1
-) edit user-accounts

The user got the role "example". Is he able to edit user-accounts in subtree 2 although he has no read access in subtree 2?

What is the best way to manage roles?
-) Create one role for each "user class" (user, editor, chief editor etc.) with all necessary policies and assign only one role to the specific user ...
-) or create one role for each "user class" with only the "additional" policies.

By the way, in ez 3.2.3 the role system sometimes don't work as expected.

e.g. if you want to have "subtree limitations" don't do following:
-) role "example 3"
---- read subtree 1
---- read subtree 2
---- read subtree 3 (and so on)

I think - in the theory - this should work (shouldn't it?), but it won't. (I reported this in a post somewhere else)

Instead do this:
-) role "example 3"
---- read subtree (1,2,3)
(so put the limitations in one policy instead of creating three policies)

Kind regards,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004