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
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
"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!
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?
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!
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.
Future Possibilitiesthe 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 practiceThis 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 :)
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.
If the admin needs deviating permissions for an object he can set security_inherit_p to 'f' and grant any permissions he pleasesIf 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.