---------- Forwarded Message ----------
Subject: Re: TURBINE_GROUP again (was Re: More deprecations in the
security Service)
Date: Wed, 16 Apr 2003 15:52:39 +1000
From: Rodney Schneider <[EMAIL PROTECTED]>
To: "Turbine Developers List" <[EMAIL PROTECTED]>
On Thu, 10 Apr 2003 08:25, you wrote:
> Hi All. (Long time no see :-)
>
> Long ago I made a lot of noise about how badly
> named I think TURBINE_GROUP is. (I made a lot
> of noise about other things too.)
>
> A TURBINE_GROUP isn't a group of people, but a
> group of application features. The name is
> entirely confusing, but George groks it. At
> least that's how I understood it from various
> posts by Rafal even longer ago.
Hi all,
Long time no see too...
I thought I would send you some thoughts about the security service
from various Turbine developers over the years. This might help you
understand the user/group/role/permission system better... I collected
these notes from the mailing list archives when I first started using
Turbine.
------------------
A user can have multiple roles at the same time and a user can have a
role in a specific group. For example you can be a Developer in group
ProjectX and Supervisor in group ProjectZ. There are roles that are
not associated with any particular group but are system-wide (like
turbine_root role). Those roles are associated with the special group
'global'.
A user does not *belong* to a group.
An 'user' has a 'role' *in* a 'group'.
A number of groups exists in the system. The groups might be projects
for example. You can have one or more roles in those groups. You might
be an observer, developer or supervisor. Different roles are assigned
different sets of permissions.
A 'group' is a developer defined label which is given to a collection
of screens and actions (modules).
A 'permission' is a developer assigned label which says "I don't
really care who is using this code, they just need the DISPLAY_PRICE
permission in order to proceed."
So in the template you might find something like this
#if ($data.ACL.hasPermission("DISPLAY_PRICE"))
## display the price column here
#end
To configure the system during deployment, assign a collection of
permissions to a given role, and then assign users different roles
within the groups.
The permissions are the individual things a user is allowed to do/view
in the system.
A role is a container for the permissions. A role can be made up of
many permissions.
A group is a something that a user would want to do/view something in.
A group has often been described in the same way as a project or
department. In a project or department you fulfill a role, however a
user doesnt "belong" to a project or department they merely have a role
in that project or department.
A user can have many roles within one group. For instance a user may
have the Developer role in the Advertising group, but may also have the
Administrator role in the Advertising group as well.
------------------
Sorry I don't have time to clean these notes up into a decent document.
Regards,
-- Rodney
-----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
