[horde] Group permissions model
Richard Wallace
rwallace at thewallacepack.net
Thu Oct 21 08:51:14 PDT 2004
Aright, here's what I've come up with for a mapping. I've attached two
diagrams, the first (1.png) is what the actual organizational structure
looks like. The second (final.png) is the mapping that I've come up
with. It's workable, but messy.
I'd appreciate some feedback.
Thanks,
Rich
Richard Wallace wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: final.png
Type: image/png
Size: 55382 bytes
Desc: not available
Url : http://lists.horde.org/archives/horde/attachments/20041021/ff7de0b6/final-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 31556 bytes
Desc: not available
Url : http://lists.horde.org/archives/horde/attachments/20041021/ff7de0b6/1-0002.png
More information about the horde
mailing list