Thanks for that Claudio.
I agree, but that's not the table I was referring to. As I said, our ACS_PERMISSIONS table is the one that's enormous, and as far as I can tell the reason for that is because our system isn't taking advantage of the hierarchy, and I'm trying to work out why that is.
In fact, the situation we're getting is specifically referenced in that document:
The naive approach to managing system security would be to require application developers to store permission information explicitly about every object, i.e. if the system has 100,000 and 1,000 users who have the read privilege on all objects, then we would need to store 100,000,000 entries of the form:
object_id grantee_id privilege
object_id_1 user_id_1 'read'
object_id_1 user_id_2 'read'
...
Although quite feasible, this approach fails to take advantage of the fact that objects in the system are commonly organized hierarchally, and permissions usually follow the hierarchical structure, so that if user X has the read privilege on object A, she typically also has the read privilege on all objects attached under A.
The general permission system, as implemented in OpenACS 4.x, takes advantage of the hierarchical organization of objects to unburden developers of the necessity to explicitly maintain security information for every single object. There are three kinds of hierarchies involved. These are discussed in the following sections.
It seems that for some reason our hierarchy is being built using acs_rels objects rather than parties, and the hierarchy traversing code isn't able to follow via acs_rels, if indeed it's trying to. As I said, I'm pretty new at this and don't know where to look to diagnose what's actually going on.
You said
Group's hierarchy is great to simplify permission management, but the actual permissions are maintened at detail level.
however the document would appear to suggest the opposite.
Incidentally, I pored over the "tediously explained" document in some detail, and was a little confused by the following:
The code has been modified since this document was written so it is now out of date.
Why is this document included in current documentation if it had been marked as Out Of Date in 2003? It's a great & helpful document, disadvantaged only by the big disclaimer at the top saying "the product hasn't actually worked like this for some time now"...
