Forum OpenACS Development: logical site hierarchy

Posted by Peter Marklund on

I would like to resurrect my favorite ACS Object topic that was never given a satisfactory answer at aD, namely the issue of a logical site hierarchy.

Websites implicitly organize their ACS objects into a tree structure that the user can navigate. However, AFAIK this structure does not have a generic and consistent representation in the OpenACS datamodel (beyond the site-map). Some developers have used/abused the context_id column to represent this hierarchy but there seems to be no consensus on best practise here (which is a sad thing because I was hoping to reach such a consensus more than a year ago...). What I am aiming for is an easy, scalable and generic way to answer the following two questions (in order of importance):

  • Which package does this object belong to?
  • What is the logical parent of this object? When I wrote a categorization API for ACS 4 TCL we needed to be able to answer this question.

Someone who wants more background information on this issue might have a look at although it is very long and only partially relevant.

I would like to boldly lay the following options on the table for discussion:

  • Dictate that context_id represents both a logical and security (permission) hierarchy. If someone needs special permissions for certain objects they can set security_inherit_p to false and grant direct permissions. I think this is the option that best balances simplicity with generality and power. I got this idea from Vadim Nasardinov who in the above mentioned thread wrote:
    "Having done some coding with ACS 4.x, I am of the opinion that, in practice, it would be too much pain to maintain two mostly overlapping hierarchies. I haven't encountered any specific cases where doing so would be justified. The context tree is the simplest thing that could possibly work."
  • Add an extra column to acs_objects called parent_id for the logical site hierarchy.
  • Assert that we don't need a site hierarchy that stretches beyond the site map and add a package_id to acs_objects.

Any comments on this issue would be appreciated!

Posted by Lars Pind on

I'd definitely go with Vadim's proposal, for simplicity's sake.

I'd definitely like a clear hierarchy of objects, although I'm having problems visualizing how this'd work in practice in the interface. Can you give an example of what you're thinking here?

Posted by Peter Marklund on

I am somewhat embarrassed to admit that I haven't thought too much about the user interface aspect of things... :-) However, off of the top of my head the following are two GUI applications that would be feasible with a consistent context hierarchy:

  • Category browsing widget. As part of the categorization service we developed a widget that could be dropped into for example a Bboard forum. The categorization service would fetch all categories that were mapped to objects underneath the forum object in the context hierarchy. Thus Bboard posts could be nicely navigated in a tree of categories. Note that such a generic widget requires that the name and url of the objects can be fetched efficiently.
  • Browsing all objects on your site. This is maybe only useful as part of site-wide administration (if at all, I'm not sure). Starting at the main site (package) object you could drill down and find every single user-submitted piece of content on the site.

Lars, after your post I feel more confident that we can reach consesus on this issue this time which would be great!

Posted by Don Baccus on
Another possibility - make context_id reflect the physical structure but add another field, default NULL, that overides it for permissions inheritance only.  I'd have to look into the various queries on permissions to convince myself that it wouldn't slow things down.

This presumes there's usefulness in the current scheme which allows you to control the inheritance hierarchy for permissions.  In theory it seems there is, in practice I have doubts.  It would give us a way to make the standard OACS 4.5 solution follow the physical hierarchy while giving those who need greater flexibility a built-in hook for doing so.

This way only those who need the flexibility need pay the cost of maintaining two hierarchies.

Posted by Jim Lynch on
I'm not sure whether the intent here is to discuss future possibilities of the data model or good current practice... so maybe I post about both :)

  • Future Possibilities
    the name context_id is suggestive of structure more general than just for security, so howbout renaming it to something much more suggestive of its actual use, like permission_tree_parent_id? Then the name context_id becomes available... and people presently (and incorrectly) using context_id to reflect some sort of package structure other than permission heirarchy would have to add that column to an aux table.

    Hmm, if people actually get onto that, it could solve some problems...

    Then again, it would add a fairly deep change to the data model, so all or most packages would have to be edited.

  • Current practice
    This part is carved in stone... or is it?

    • On the one hand, you had the acs core team documenting "hands OFF context_id! Using it for anything but permission heirarchy is a bad idea!"
    • On the other hand, you had aD employees doing just that, creating things for openacs to fix :)
    Look at it this way, it might be possible to set the context_id to null by using the permissions ui.. and doing so, might affect the structure of the package.

    It would be for at least this reason you would want to stay clean away from overloading extra meaning on context_id or really any other field in the core data model.

Posted by Don Baccus on
Right ... depending on context_id in this way means you're vulnerable to an admin breaking your code for you.
Posted by Peter Marklund on
My answer to this vulnerability is to not allow the admin to change the context_id. In the interest of simplicity there should only be one site hierarchy used both for permissions and for navigation. If the admin needs deviating permissions for an object he can set security_inherit_p to 'f' and grant any permissions he pleases. The group and privilege hierarchies already offer plenty of power and flexibility in granting permissions.
Posted by Don Baccus on
If the admin needs deviating permissions for an object he can set security_inherit_p to 'f' and grant any permissions he pleases
If this worked I could accept it as a solution, but it doesn't. security_inherit_p controls whether or not to inherit when the object is instantiated. Setting it to false afterwards doesn't do anything. To kill the inherited perms you must set context_id to NULL.

Perhaps this should be considered a bug?

I haven't looked to see what the admin page does, actually, it may mistakenly just set "security_inherit_p" to false.

From an abstract point of view I agree with wanting simplicity, and certainly context_id has been frequently abused. If we go this way we should do it right, though. It should be renamed "parent_id" and the parent_id field found in the content repository objects be dropped, along with those in other packages. In other words, if we do it let's get rid of all opportunity for confusion and error in one fell swoop.

Obviously this would involve writing a lot of upgrade scripts but both Oracle and PG support renaming and PG 7.3 will have column dropping (in PG 7.2 we could just rename the CR's parent_id to some garbage name).

Clearly this is too much for 4.6 but perhaps 4.7?

If we *do* decide to take this path it should be a conscious decision, though. Currently depending on context_id being set to the parent is an error.

Posted by Barry Books on
I think that must be a bug. I'm running 4.2 on oracle and there is an update trigger on acs_objects that rebuilds the object_context_index. It's named acs_objects_context_id_up_tr but it also checks security_inherit_p.
Posted by Peter Marklund on
Don, I agree with everything you say. I hope we can agree on this approach and make 4.7 our target.