Forum OpenACS Development: Adding a parent_id to acs_objects ...

Collapse
1: Adding a parent_id to acs_objects ...
Posted by Don Baccus on 02/09/04 05:20 PM
Since we're in the midst of munging the basic object definition by adding titles and package_ids, would this be the time to add a real parent_id, with the goal of differentiating context_id and parent_id, and eventually removing the CR's parent_id (as we will eventually with the CR's title column)?

This would make programming for generic objects and CR objects  more consistent, and would end confusion over the proper role for context_id.

And, as a matter of fact, I've been contemplating removing context_id for permissions entirely.  The column is only used by triggers that maintain the denormalized context_id table (as is the case for the security_inherit_p column as well) so, other than its use as a physical parent_id it is wasted space.

And time ...

The notion here is to remove context_id (or actually rename it parent_id) and to have the programmer make explicit PL/[pg]SQL calls to change the permissions hierarchy or security inheritance for an object.  I think the explicit calls would not only simplify acs-kernel but would be more clear for the newcomer studying how OpenACS works, it's a bit of magic to hang a bunch of consequences on simple UPDATEs to context_id or security_inherit_p via triggers IMO.

Discussion?

Collapse
2: Re: Adding a parent_id to acs_objects ... (response to 1)
Posted by Tom Jackson on 02/09/04 06:49 PM

Sounds good to me. Would it be possible, once context_id were in its own table, to have multiple contexts for an object, that is permissions on several higher up objects could be used to grant permission on the lower level objects? Even though it make perfect sense that there be only one partent of an object, multiple contexts should be possible.

The morass of triggers makes it difficult to figure out how the kernel works, I guess the end result is that applications would need to add an additional database call to set the context. A tcl call along the lines of set_object_context(:object_id,:context_id) would make it simple.

Collapse
3: Re: Adding a parent_id to acs_objects ... (response to 1)
Posted by Don Baccus on 02/09/04 07:03 PM
Yes, I was thinking in terms of providing both Tcl API and PL/[pg]SQL API.

As far as your first question goes I suppose it would be possible to do as you ask, though I've not thought of it before.  It would actually make it simple to solve a .LRN permissions problem we're currently dickering about in e-mail now that you mention it.

The notion would be to add one parent-child row to the context hierarchy table rather than zap it with all a child's parents as is done when security_inherit_p is true.

Hmmm ... interesting idea.  There's a utility vs. confuse-the-programmer trade-off to consider, though.

Collapse
4: Re: Adding a parent_id to acs_objects ... (response to 3)
Posted by Tom Jackson on 02/09/04 07:40 PM

So could the security_inherit_p just be a flag to the same proc to loop over the necessary inserts?

Security inherit is the default now, isn't it? In ad_proc format: 


ad_proc some_context_setting_proc {
   {-object_id}
   {-context_id}
   {-security_inherit_p "true"}
} ...

which would just wrap the pl procedure taking the three arguments. Or optionally you could specify the number of levels up the hierarchy to go. Zero would be the same as setting security_inherit_p to "false", -1 could imply all the way up??? Some positive number would indicate an intermediate inheritance. So something like -inherit_levels "-1" would be the default.

Collapse
5: Re: Adding a parent_id to acs_objects ... (response to 1)
Posted by Jade Rubick on 02/09/04 08:17 PM
Don, I think this is a great idea.

We'll need some time to move over applications that are depending on the use of context_id, however. I'm writing one in the next few days, actually.

So as long as we take some time before removing context_id, I'm fully in support of this.