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

I think the answer is that we do have a create privilege, and the trick is that, when you want to create an object, you have to figure out what the "parent" object should be and test for "create" on that object.

Btw, the 'trick' is called 'ad hoc'. It isn't a trick, it just points out the fact that one pemission can be a proxy for others. This is my entire point. Permissions do not have an inherent meaning, but derive meaning by how you use them in the application. You could just as easily require 'write' on the parent object in order to create child objects. But please explain how you are going to handle the case of two different types of child objects. One should be created by one group of users, the other created by a second group of users. Some users can create both. The single 'create' privilege on the parent object is no longer enough. If you, or Don can explain how to do this with permissions, without creating new privileges, please explain.

The permission system doesn't support roles, that is you can look in the database all day long and never figure out what role a user plays, or could play. All this is coded in the UI/application layer. Unfortunately it has limitations if you just use the permissions data model.

Also, you will see the limitation of the permissions model when you consider how users can create or modify objects. It is useful to prohibit users from modifying or setting certain attributes of an object. One create/modify permission cannot control or specify this behavior. To an extent a static UI can help. In OpenACS there are two 'roles' which are statically supported. This is the regular user and the admin user. The admin user has access to the package admin directory, thus allowing greater access to the object attributes. Sometimes the admin functions are placed in the regular user section of the package, but they don't work or even show up unless the user is an admin. These are static roles defined in the application layer. One permission is used as a proxy for greater control over a number of objects and attributes. It is efficient and useful.

The only place I know of where roles are explicitly defined is in the workflow package. And why does it use roles? Because they were necessary to generate a UI dynamically. Whenever you move to a dynamic UI, you must use roles.

Look at it this way: a permission is just data, one tiny piece of data. There isn't a lot of entropy there, so you can't expect it to do too much all by itself. If you have a simple situation, you don't need much entropy. But, to all the scientific types out there, complex systems require more data to represent them. The only question is where is the data going to be stored, and in what format. The permissions data model is unsuited for this in its current form because it requires the existence of the object. Otherwise you have to infer meaning using an ad hoc method from other permissions. As long as you have two roles this works well most of the time when combined with the UI conventions.