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.
