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

Collapse
Posted by Tom Jackson on

Joel, the problem of just adding terms, new privileges, sub-privileges, whatever, is that it doesn't solve any issue, and in fact, makes things worse. If 'read', 'write' and 'admin' have camellian like properties, subdividing these isn't going to help anything. The UI determines the meaning of this data.

Here is my analysis of the situation, expressed in code in my query-writer package.

An object is composed of attributes, so I divide up objects into attributes. You can only do a few things to object attributes: create, update, view. You can also delete an entire object, but I view this as delete of the object_id, so delete only applies to the object_id attribute.

To control access to an object I create roles. Actually in query-writer two roles are 'assumed': users who have admin on the security root context, are in the admin role, otherwise they are in the default role. Otherwise new roles can be created by creating a rel_segment and placing users in it. But what a role is allowed to do, is defined outside of the acs object system, it is part of query-writer. So first query-writer picks a role, then validates that a request to create, update or delete object attributes is possible within the role. Once this validation passes, for updates I require 'write' permission on the object, and for delete I require 'admin'.

Also certain roles can be limited to certain value choices for an attribute. For instance if an object attribute was 'publish_p', you might want to limit setting the value to '1' to the 'publisher' role. Although both the writer and editor would have write access to the content related attributes, they shouldn't have access to other metadata attributes.

I'm sure the workflow package addresses the same issues because it allows variable access to objects depending on a user's role defined in the workflow. But in the end this is necessary when you want to auto generate variable access to objects. If you can hand write the UI, you don't need a formal model to follow, and requiring one might be counterproductive.