Actually, I know that I can create a child_privilege and this is what I thought I should do, but this does not in any way address the problem that I am talking about, which is:
- more about a user being able to assume different roles in a system. Maybe it is only top level admins which have this problem, but in general the hierarchy as used causes this problem.
- about the automatic creation, through views, of completely bogus direct permissions, and I haven't even checked the other types.
Maybe the idea of a hierarchy of privileges is the true problem. I completely understand the hierarchy of objects, using the context_id, etc. But what does the hierarchy of privileges really get us? I think that figuring out if a user is an admin, and of what type, could be easier that the use of the magical object 0 (zero). Think about it, this system assigns every possible privilege on every object created to the superuser. This is obviously total nonsense. If you are going to grant every privilege, why grant any? There seems to be a crucial difference between the use of context_id and the privilege hierarchy. Context_id explicitly passes privileges up, whereas the privilege hierarchy automatically passes privileges down.
Also, just to complain a little, I don't really see why my idea of a shortcut of checking for direct permissions is a loss of the abstraction. The abstraction was lost already long ago when we realized that it didn't work for a reasonably small set of objects, and some extremely bright individuals rewrote the pemission_p procedure. My suggestion is to simply test one arm of this procedure in the case where direct permissions are assigned, and the designer wants only direct permissions to apply. In my particular case I think it makes perfect sense: I aggregate all privileges around a single object type by using the context_id of sub-object to point up, I assign privileges to this object for a group of users. Permission_p would still work to check if user x has right to read sub-object a, but a direct check is much quicker, and is exactly what is implied by the initial assignment.
The problem is, I don't want to create new sematics in a package I want to release for general use. If it is worth holding off on this hacking, speak up and I'll just use permission_p.
