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

31: Re: Best Practices for permissions, straw man (response to 1)

Posted by Don Baccus on 12/10/03 08:02 PM

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.

Naw, "create" is just shorthand for "allow the creation of a child object" ...

How is this different than the write privilege on a Unix directory, which says "you can write this file, and that includes adding a child file or deleting a child file"?

This is my entire point. Permissions do not have an inherent meaning, but derive meaning by how you use them in the application.

Of course. The whole point of developing a coding standard for permissions is to make the use of permissions consistent because the permissions system does not define semantics.

Are you suggesting it should? If so, make a solid suggestion. I'm personally comfortable with the fact that it doesn't, because in practice permissions are simple and easy to use and have proven to be both flexible and (with some tweaking on my part) efficient.

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.

Create two container objects, which if you're using the content repository would be of type "content_folder" and put the create child permission on that object.

If you're going to segment content between two user communities like this doesn't it make sense to reflect that in the hierarchical structure of objects you build?

32: Re: Best Practices for permissions, straw man (response to 31)

Posted by Tom Jackson on 12/10/03 09:34 PM

Create two container objects, which if you're using the content repository would be of type "content_folder" and put the create child permission on that object.

So are you saying stick another layer of objects between the parent and the child.

How is this different than the write privilege on a Unix directory, which says "you can write this file, and that includes adding a child file or deleting a child file"?

My point exactly, it isn't different. Unix doesn't have a separate create privilege. In this case, as you say, the directory is a container. If you are going to create separate objects just for permissions, you don't need extra privileges.

Are you suggesting it should? If so, make a solid suggestion. I'm personally comfortable with the fact that it doesn't, because in practice permissions are simple and easy to use and have proven to be both flexible and (with some tweaking on my part) efficient.

I've said exactly the same thing a few times in this thread already: the flexibility is a good thing, it is efficient to use a proxy, usually parent permissions. My only suggestion is to remove the create privilege, and I've made that suggestion pretty solidly. However, I agree that it can be useful. Agreeing with this, I would have to ask: why not others? Why not a delete privilege?

I'll drop the attribute level discussion, since it appears to be off topic.

Anyway, I must have missed the whole point of the discussion, as usual. The read priv is for reading, write for writing, admin for admining and create for creating. It really would take a numbskull to mess this up.