Forum OpenACS Development: logical site hierarchy

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 http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000KO5&topic%5fid=ACS%20Design&topic= 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!

Lars,
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!

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.

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.

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.