[horde] Group permissions model

[Richard Wallace]

Hey all,

I'm trying to map our clients organizational structure to the Horde 
group model.  The way the Horde model works is that permissions flow 
down.  But in an organizations structure permissions typically don't do 
that and I'm having a problem mapping the one to the other in a logical, 
manageable fashion.

Here's the basic structure (forgive the ascii art):

+ Company 1
|
--+ Devs
| |
| --- DEs
|
--+ Pubs
| |
| --+ Pub1
| | |
| | --+ AEs
| |   |
| |   ---EAs
| |
| --+ Pub2
|   |
|   --+ AEs
|     |
|     ---EAs
|
--+ Marketing
| |
| -- MM
|
--+ Sales
   |
   --+ Regional manager 1
   | |
   | --+ District manager 1
   | | |
   | | --- Reps
   | |
   | --+ District manager 2
   |   |
   |   --- Reps
   |
   --+ Regional manager 1
     |
     --+ District manager 1
     | |
     | --- Reps
     |
     --+ District manager 2
       |
       --- Reps

So the high level group is the "Company".  People that are members of 
this group are like executives and they should be able to see all things 
belonging to all groups.  For each level down the persons 
responsibility, and therefore access rights, diminishes within the 
organization.

This is the opposite of the way the Horde group permission inheritance 
works, where the child gets the access permissions of the parent and may 
have more added on.  Instead, the top level group should have all the 
rights of its children.  Representing this in Horde wouldn't be a 
problem if a group could have multiple parents, then we could literally 
just flip the above tree upside down and that would be that.

Has anybody run into this problem before?  I understand the way the 
Horde group stuff is modeled from an implementation point of view.  It's 
much easier to start at a node and visit each of it's parents gathering 
permissions that to try and recurse a tree from the top to get the 
permissions.  But most users don't think that way.  Most organizations 
will be organized the way I have outlined above, where the top guy gets 
the most access.

I've thought about a variety of ways to handle this.  The two best were 
1) create a layer on top of the group system that handles mapping 
between the two different models, but this would get pretty hairy really 
quick, and 2) just flattening out the groups and programatically 
managing the relationships, which also seems like it would be an ugly mess.

So what do you guys think?

Thanks,
Rich