Forum OpenACS Development: Re: Best Practices for permissions, straw man

Collapse
Posted by Dave Bauer on
Tom,

You can define roles as acs_rel_types between a group and a user. Then a relational_segment of all users which are members of a group in a certain role can be created.

Right now I think built in are membership_rel and admin_rel.
An application can define additional rel_types to create a new role.

You are correct there is no built in meaning to privileges, they are application specific.

The system is very flexible, in that it imposes very few rules on how it is used. There is a need for better examples of how it can be used.

Collapse
Posted by Tom Jackson on

Dave, a 'role' is not a sub-group, which is essentially what a rel_segment represents. A rel_segment is a group of users which have a defined relationship to a specific group. A group, in OpenACS is a collection of parties. A 'role' is a collection of rights on objects. We don't have an explicit 'role' in OpenACS. If you assign someone to an admin rel_segment of a group, they don't get anything from that. The application has to 'assume' a meaning of that membership type, implicitly creating a role. But there is no data model, no table where roles are defined in OpenACS.

I think workflow has it's own user->role map. My query-writer package uses rel_segments to place users in a role, but the role itself is defined in separate tables, separate from the application.