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.
