>
> 1. Should we nest orgs?
>> I think the answer here is a resounding "yes", but figured should kick
>> off with this question.
>
>
> I think we definitely should do nested orgs in some capacity. I'm not sure
> I see the value in nested organizations that act like hostgroups, where all
> the permissions from the parents flow down into the children. I think they
> are more of a tool to group together different tenants/divisions/BU's and
> provide hierarchy than to manage users/groups/domains, etc in a more
> specific manner and then override them on a per-object basis. Greg, we
> spoke about this yesterday and I think you understand it well so if you're
> about to explain it more eloquently than I am, feel free to do so 
>
Ha! I have you fooled 
Here's my current understanding (somewhat reiterating what you just said):
Orgs are a way to provide some form of multi-tenancy. You can group system
objects together into an organization and control access to those objects
by providing different users access to the organization. This is
markedly different from user roles and permissions. You may have access to
create domains, but when you create a domain organizations will restrict
who gets to see the domains.
At this point, organizations are purely flat (i.e., they're all siblings).
There is no concept of parent organizations.
If we go with a nested model, well it raises all these questions (and
more?) from this thread. However, in our hallway conversation, the one
main point of enlightenment was that if we allow nested orgs but don't
cascade object associations, it's not much different (in a sense of
mathematics) from staying with strictly sibling organizations. In this
case, each org is still an island, whether it has a parent or not.
This sorta argues that if we go with nested orgs, we need to also go with
cascading object associations (virtually, not physically cascade the
relationship). In other words, if I'm in OrgB, which has a parent of OrgA,
I will be able to see all the object associations in Orgs A and B (just an
example; we would still need to figure out if cascading up or down the tree
is the right approach).
If we introduce the concept of permissions to organizations (perhaps
through an expanded concept of user groups [permission groups?]), we then
have to deal with the problem of cascading permission sets and permission
conflicts. Whereas cascading object associations is purely additive (I
think), cascading permission sets can be additive or subtractive.
···
On Friday, July 27, 2012 11:25:55 AM UTC-4, Sam Kottler wrote:
- Can users belong to middle-nested orgs? I.e., non-leaf nodes
Again, I believe the answer here is “yes”. Mainly b/c if the answer is
“no”, then it automatically makes orgs with associated users leaf-nodes ad
infinitum.
Yes and I agree with the reasoning, here.
Questions 3-5 require some answers to these first two, so I’m going to
leave my responses at that so we can sort out the nesting situation before
dealing with the ins-and-outs of how the user/permission cascade will work.
On Thu, Jul 26, 2012 at 12:50 PM, Greg Blomquist wrote:
-
Should we nest orgs?
I think the answer here is a resounding “yes”, but figured should kick
off with this question.
-
Can users belong to middle-nested orgs? I.e., non-leaf nodes
Again, I believe the answer here is “yes”. Mainly b/c if the answer is
“no”, then it automatically makes orgs with associated users leaf-nodes ad
infinitum.
-
Do organizational associations cascade down the tree?
Assume the answer to Q2 is “yes”.
Given orgs with ancestry Parent → Middle → Child
Given UserX belongs to Parent and UserY belongs to Middle, and UserZ
belongs to Child.
Given Parent is associated to Domain me.here.com.
Given Middle is associated to Domain you.there.com.
Given Child is associated to Domain them.there.com.
What domains can UserX, UserY, and UserZ see?
-
Do we integrate permissions into orgs? Should UserX be able to have
different permissions on domains in Org1 than in Org2?
This is probably where this starts to collide with User Groups the most.
-
Assuming the answer to Q4 is “yes”, then Q3 should also be applied to
permissions in Orgs. But, in a more complicated way 
Given orgs with ancestry Parent → Middle → Child.
Given Parent is associated to Domain me.here.com.
Given Middle is associated to Domain you.there.com.
Given Child is associated to Domain them.there.com.
Given UserX belongs to Parent with :view_domains.
Given UserX belongs to Middle with :edit_domains.
Given UserX belongs to Child with :delete_domains.
Assume the answer to Q3 implies that when viewing Org “Child”, UserX can
see all three domains.
What operations can UserX perform on each of the three Domains when
viewing Domains in Org “Child”?
These are all the questions I can come up with off hand. I’m sure
there’s more. And hopefully some of these questions can be obviated by
other’s views on this topic.
Thanks!
Greg
