Forum OpenACS Development: Re: Permission system in needs of revisit?

Collapse
Posted by Tom Jackson on
But what should I do with create? Here I need the proxy object, because I cannot give create permissions on a not yet created object. We could argue to say that "if you have create permissions on the context_id then you are allowed to create the object". But is this right? And wouldn't I still have to check if I am allowed to have write permission on the object_type?

With a role, you don't give role permissions to the individual objects, just the object type, so there is nothing different with create (in query-writer this is the 'new' operation). But another point to keep in mind with roles is that the not only filter the base objects, but the role can span multiple object types.

Otherwise, in order to allow users to serve in a role, you would have to assign multiple permissions. This could get confusing as roles may overlap, and if you remove a user from a role, you might damage the other role configuration.

Here I'm just speaking in general about a role and how it differs from objects and permissions on objects. In other words, think of roles as something layered on top of the main objects of interest. It is a description of what you can do, and a container for allowing users to assume a particular role.

In query-writer, I have one default admin group. It doesn't require any extra permissions, the user has to belong to the admin rel_segment (for the site). Even then, you could use a separate admin rel_segment to create a less expansive admin role. What I have found works best is for each package to configure their own roles which don't extend beyond the objects in that package, however, these could include objects which were initially created by another package. So for a particular package, the role assignment happens once for each user (for each role they can assume). For most applications, you don't even need to do this, the defaults work for an admin and regular user of the package.