Organization/Location

Petr_Chalupa · May 9, 2014, 12:12pm

Hi,

sending my 2 cents:

Everything should be assigned to at least one organization as suggested.

Any Context should mean union of all your organization you can access.
(It could also be allowed to select a subset of that.) (In code I would
always tread context as collection of orgs and locations even if only
one is selected. It should simplify the design.)

All resources have uniq names in organization not globally (with
exception Ohad mentioned). Auto disambiguation of resources could be put
in place by automatically adding columns with organization and location
into lists whenever more of them are selected.

Foreman mode without organization would go away (big simplification of
code base). Same functionality would be achieved by creating a default
organization which would be always automatically used when Organization
are disabled (same logic would work for users isolated into one
organization only). Migration from disabled to enabled organizations
would be simple - just unhiding few UI controls (context selection,
organization crud pages).

Each auto created resource would use organization assigned to its parent
object (e.g. Discovered host would go to an organization based on its
subnet's organization). This idea needs more detailed go-through.

Isolation of organization: If everything belongs to a single
organization and no names have global uniq names all is fine. When
something is shared between organizations (useful for super-admins and
power-users) it would make sense to allow editing of such resources only
if user can edit them in all of the resource's organization. (e.g.
resource R belonging to orgs A and B can be eddied only if user U has
permission to edit R in both A and B orgs.) That would prevent
accidental changes of shared resources. It would be also nice to mark
all shared resources in UI with small icon or something.

I think this could solve most or all the problems mentioned on the call,
but I am maybe missing something, I'll appreciate any feedback.

Petr

Marek: How does the new permission system behave in situation I've
described above? I think we talked about something similar but not sure
how it ended up implemented.

iNecas · May 12, 2014, 8:29am

> Hi,
>
> sending my 2 cents:
>
> Everything should be assigned to at least one organization as suggested.
>
> Any Context should mean union of all your organization you can access.
> (It could also be allowed to select a subset of that.) (In code I would
> always tread context as collection of orgs and locations even if only
> one is selected. It should simplify the design.)
>
> All resources have uniq names in organization not globally (with
> exception Ohad mentioned). Auto disambiguation of resources could be put
> in place by automatically adding columns with organization and location
> into lists whenever more of them are selected.
>
> Foreman mode without organization would go away (big simplification of
> code base). Same functionality would be achieved by creating a default
> organization which would be always automatically used when Organization
> are disabled (same logic would work for users isolated into one
> organization only). Migration from disabled to enabled organizations
> would be simple - just unhiding few UI controls (context selection,
> organization crud pages).

Big +1

>
> Each auto created resource would use organization assigned to its parent
> object (e.g. Discovered host would go to an organization based on its
> subnet's organization). This idea needs more detailed go-through.
>
> Isolation of organization: If everything belongs to a single
> organization and no names have global uniq names all is fine. When
> something is shared between organizations (useful for super-admins and
> power-users) it would make sense to allow editing of such resources only
> if user can edit them in all of the resource's organization. (e.g.
> resource R belonging to orgs A and B can be eddied only if user U has
> permission to edit R in both A and B orgs.) That would prevent
> accidental changes of shared resources. It would be also nice to mark
> all shared resources in UI with small icon or something.

+1

···

----- Original Message -----

I think this could solve most or all the problems mentioned on the call,
but I am maybe missing something, I’ll appreciate any feedback.

Petr

Marek: How does the new permission system behave in situation I’ve
described above? I think we talked about something similar but not sure
how it ended up implemented.

–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ohadlevy · May 13, 2014, 11:18am

> Hi,
>
> sending my 2 cents:
>
> Everything should be assigned to at least one organization as suggested.
>
> Any Context should mean union of all your organization you can access. (It
> could also be allowed to select a subset of that.) (In code I would always
> tread context as collection of orgs and locations even if only one is
> selected. It should simplify the design.)
>
> All resources have uniq names in organization not globally (with exception
> Ohad mentioned). Auto disambiguation of resources could be put in place by
> automatically adding columns with organization and location into lists
> whenever more of them are selected.
>
> Foreman mode without organization would go away (big simplification of
> code base). Same functionality would be achieved by creating a default
> organization which would be always automatically used when Organization are
> disabled (same logic would work for users isolated into one organization
> only). Migration from disabled to enabled organizations would be simple -
> just unhiding few UI controls (context selection, organization crud pages).
>

> Each auto created resource would use organization assigned to its parent
> object (e.g. Discovered host would go to an organization based on its
> subnet's organization). This idea needs more detailed go-through.
>
what happens when a subnet is shared across orgs?

this is where the resource exists only in one org model breaks down when it
comes to infrastructure, its perfectly fine for both orgs (QA and ENG for
example) to share the same physical subnet, or same virtualization
infrastructure.

>
> Isolation of organization: If everything belongs to a single organization
> and no names have global uniq names all is fine. When something is shared
> between organizations (useful for super-admins and power-users) it would
> make sense to allow editing of such resources only if user can edit them in
> all of the resource's organization. (e.g. resource R belonging to orgs A
> and B can be eddied only if user U has permission to edit R in both A and B
> orgs.) That would prevent accidental changes of shared resources. It would
> be also nice to mark all shared resources in UI with small icon or
> something.
>
> I think this could solve most or all the problems mentioned on the call,
> but I am maybe missing something, I'll appreciate any feedback.
>

Defaulting to a forcing at least one default org is fine (just like we have
for the admin user when auth is turned off), but I'm not sure it actually
simplify anything (besides of adding more SQL), what we really want to do
is to auto attach all resources (or turn off filtering) when there is only
one org/location.

Ohad

···

On Fri, May 9, 2014 at 3:12 PM, Petr Chalupa wrote:

Petr

Marek: How does the new permission system behave in situation I’ve
described above? I think we talked about something similar but not sure how
it ended up implemented.

–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marek_Hulan · May 14, 2014, 11:37am

Hello,

permissions does not work the way you've described. We search for filters on
particular resource, then merge their conditions using OR. Part of condition
can be taxonomy condition like this:
(name = abc) AND (taxonomy condition)

taxonomy condition is always joined by OR, so e.g.
organization = A OR organization = B

Therefore user can edit resource R belonging to org A and B if they have at
least one filter matching R with edit permission and this filter is belonging
either to no org, org A or org B (or both).

It's getting more complex if you think about nested organizations. But I think
in model you've described the inheritance wouldn't be needed anymore. By
selecting context you could select the whole tree if you want.

I generally agree with the proposal, but you permission description does not
make sense to me. If I can edit resource in one scope why should we check
permissions in different scopes?

Also I don't understand what you mean by "use organization assigned to its
parent object". What's parent object of new hosts that registers itself to
foreman during puppet run?

···

-- Marek

On Friday 09 of May 2014 14:12:04 Petr Chalupa wrote:

Hi,

sending my 2 cents:

Everything should be assigned to at least one organization as suggested.

Any Context should mean union of all your organization you can access.
(It could also be allowed to select a subset of that.) (In code I would
always tread context as collection of orgs and locations even if only
one is selected. It should simplify the design.)

All resources have uniq names in organization not globally (with
exception Ohad mentioned). Auto disambiguation of resources could be put
in place by automatically adding columns with organization and location
into lists whenever more of them are selected.

Foreman mode without organization would go away (big simplification of
code base). Same functionality would be achieved by creating a default
organization which would be always automatically used when Organization
are disabled (same logic would work for users isolated into one
organization only). Migration from disabled to enabled organizations
would be simple - just unhiding few UI controls (context selection,
organization crud pages).

Each auto created resource would use organization assigned to its parent
object (e.g. Discovered host would go to an organization based on its
subnet’s organization). This idea needs more detailed go-through.

Isolation of organization: If everything belongs to a single
organization and no names have global uniq names all is fine. When
something is shared between organizations (useful for super-admins and
power-users) it would make sense to allow editing of such resources only
if user can edit them in all of the resource’s organization. (e.g.
resource R belonging to orgs A and B can be eddied only if user U has
permission to edit R in both A and B orgs.) That would prevent
accidental changes of shared resources. It would be also nice to mark
all shared resources in UI with small icon or something.

I think this could solve most or all the problems mentioned on the call,
but I am maybe missing something, I’ll appreciate any feedback.

Petr

Marek: How does the new permission system behave in situation I’ve
described above? I think we talked about something similar but not sure
how it ended up implemented.

Justin_Sherrill · May 13, 2014, 12:14pm

>
>
>
>
> Hi,
>
> sending my 2 cents:
>
> Everything should be assigned to at least one organization as
> suggested.
>
> Any Context should mean union of all your organization you can
> access. (It could also be allowed to select a subset of that.) (In
> code I would always tread context as collection of orgs and
> locations even if only one is selected. It should simplify the
> design.)
>
> All resources have uniq names in organization not globally (with
> exception Ohad mentioned). Auto disambiguation of resources could
> be put in place by automatically adding columns with organization
> and location into lists whenever more of them are selected.
>
> Foreman mode without organization would go away (big
> simplification of code base). Same functionality would be achieved
> by creating a default organization which would be always
> automatically used when Organization are disabled (same logic
> would work for users isolated into one organization only).
> Migration from disabled to enabled organizations would be simple -
> just unhiding few UI controls (context selection, organization
> crud pages).
>
>
> Each auto created resource would use organization assigned to its
> parent object (e.g. Discovered host would go to an organization
> based on its subnet's organization). This idea needs more detailed
> go-through.
>
> what happens when a subnet is shared across orgs?
>
> this is where the resource exists only in one org model breaks down
> when it comes to infrastructure, its perfectly fine for both orgs (QA
> and ENG for example) to share the same physical subnet, or same
> virtualization infrastructure.
>
>
> Isolation of organization: If everything belongs to a single
> organization and no names have global uniq names all is fine. When
> something is shared between organizations (useful for super-admins
> and power-users) it would make sense to allow editing of such
> resources only if user can edit them in all of the resource's
> organization. (e.g. resource R belonging to orgs A and B can be
> eddied only if user U has permission to edit R in both A and B
> orgs.) That would prevent accidental changes of shared resources.
> It would be also nice to mark all shared resources in UI with
> small icon or something.
>
> I think this could solve most or all the problems mentioned on the
> call, but I am maybe missing something, I'll appreciate any feedback.
>
>
> Defaulting to a forcing at least one default org is fine (just like we
> have for the admin user when auth is turned off), but I'm not sure it
> actually simplify anything (besides of adding more SQL), what we
> really want to do is to auto attach all resources (or turn off
> filtering) when there is only one org/location.
Excluding auto-created items (discovered hosts, etc…) what is the use
in creating an object without an org selected (assuming orgs enabled)?
Nothing can use it, and it leads the user down a confusing path.
What's the purpose?

I do agree that auto-discovered things need some thought, but I can't
see any value in an unusable object without an org.

-Justin

···

On 05/13/2014 07:18 AM, Ohad Levy wrote: > On Fri, May 9, 2014 at 3:12 PM, Petr Chalupa > wrote:

Ohad
Petr



Marek: How does the new permission system behave in situation I've
described above? I think we talked about something similar but not
sure how it ended up implemented.

-- 
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Petr_Chalupa · May 14, 2014, 12:29pm

> Hello,
>
> permissions does not work the way you've described. We search for filters on
> particular resource, then merge their conditions using OR. Part of condition
> can be taxonomy condition like this:
> (name = abc) AND (taxonomy condition)
>
> taxonomy condition is always joined by OR, so e.g.
> organization = A OR organization = B
>
> Therefore user can edit resource R belonging to org A and B if they have at
> least one filter matching R with edit permission and this filter is belonging
> either to no org, org A or org B (or both).
>
> It's getting more complex if you think about nested organizations. But I think
> in model you've described the inheritance wouldn't be needed anymore. By
> selecting context you could select the whole tree if you want.
>
> I generally agree with the proposal, but you permission description does not
> make sense to me. If I can edit resource in one scope why should we check
> permissions in different scopes?

Ok as we talked today. I agree that this would not be needed. It is
responsibility of the superadmin:

not to create shared resources
or if he does, not to allow editing them by users form organizations
where it is shared, not to break multitenancy.
or if he does and allows editing, to educate the users allowed to edit
shared resources (Marking shared resources would be useful here.)

That is fine: it keeps the powerful model for super-admin and
power-users without breaking the multitenancy.

···

On 14.05.14 13:37, Marek Hulan wrote:

Also I don’t understand what you mean by “use organization assigned to its
parent object”. What’s parent object of new hosts that registers itself to
foreman during puppet run?

Petr_Chalupa · May 14, 2014, 1:20pm

>>
>>
>>
>>
>> Hi,
>>
>> sending my 2 cents:
>>
>> Everything should be assigned to at least one organization as
>> suggested.
>>
>> Any Context should mean union of all your organization you can
>> access. (It could also be allowed to select a subset of that.) (In
>> code I would always tread context as collection of orgs and
>> locations even if only one is selected. It should simplify the
>> design.)
>>
>> All resources have uniq names in organization not globally (with
>> exception Ohad mentioned). Auto disambiguation of resources could
>> be put in place by automatically adding columns with organization
>> and location into lists whenever more of them are selected.
>>
>> Foreman mode without organization would go away (big
>> simplification of code base). Same functionality would be achieved
>> by creating a default organization which would be always
>> automatically used when Organization are disabled (same logic
>> would work for users isolated into one organization only).
>> Migration from disabled to enabled organizations would be simple -
>> just unhiding few UI controls (context selection, organization
>> crud pages).
>>
>>
>> Each auto created resource would use organization assigned to its
>> parent object (e.g. Discovered host would go to an organization
>> based on its subnet's organization). This idea needs more detailed
>> go-through.
>>
>> what happens when a subnet is shared across orgs?
>>
>> this is where the resource exists only in one org model breaks down
>> when it comes to infrastructure, its perfectly fine for both orgs (QA
>> and ENG for example) to share the same physical subnet, or same
>> virtualization infrastructure.
>>
>>
>> Isolation of organization: If everything belongs to a single
>> organization and no names have global uniq names all is fine. When
>> something is shared between organizations (useful for super-admins
>> and power-users) it would make sense to allow editing of such
>> resources only if user can edit them in all of the resource's
>> organization. (e.g. resource R belonging to orgs A and B can be
>> eddied only if user U has permission to edit R in both A and B
>> orgs.) That would prevent accidental changes of shared resources.
>> It would be also nice to mark all shared resources in UI with
>> small icon or something.
>>
>> I think this could solve most or all the problems mentioned on the
>> call, but I am maybe missing something, I'll appreciate any feedback.
>>
>>
>> Defaulting to a forcing at least one default org is fine (just like we
>> have for the admin user when auth is turned off), but I'm not sure it
>> actually simplify anything (besides of adding more SQL), what we
>> really want to do is to auto attach all resources (or turn off
>> filtering) when there is only one org/location.
> Excluding auto-created items (discovered hosts, etc…) what is the use
> in creating an object without an org selected (assuming orgs enabled)?
> Nothing can use it, and it leads the user down a confusing path.
> What's the purpose?
>
> I do agree that auto-discovered things need some thought, but I can't
> see any value in an unusable object without an org.

Yeah just subnet won't work, I knew this needs more thinking. Roughly:
what about using more host attributes (e.g. domain, maybe some facts) to
choose the org and then use intersection on results on each attribute.
If there is still more orgs a parent org (or a global default org) will
be chosen.

···

On 13.05.14 14:14, Justin Sherrill wrote: > On 05/13/2014 07:18 AM, Ohad Levy wrote: >> On Fri, May 9, 2014 at 3:12 PM, Petr Chalupa > > wrote:

-Justin
Ohad
Petr



Marek: How does the new permission system behave in situation I've
described above? I think we talked about something similar but not
sure how it ended up implemented.

--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Petr_Chalupa · May 14, 2014, 1:45pm

>
>
>
>
> Hi,
>
> sending my 2 cents:
>
> Everything should be assigned to at least one organization as suggested.
>
> Any Context should mean union of all your organization you can
> access. (It could also be allowed to select a subset of that.) (In
> code I would always tread context as collection of orgs and
> locations even if only one is selected. It should simplify the design.)
>
> All resources have uniq names in organization not globally (with
> exception Ohad mentioned). Auto disambiguation of resources could be
> put in place by automatically adding columns with organization and
> location into lists whenever more of them are selected.
>
> Foreman mode without organization would go away (big simplification
> of code base). Same functionality would be achieved by creating a
> default organization which would be always automatically used when
> Organization are disabled (same logic would work for users isolated
> into one organization only). Migration from disabled to enabled
> organizations would be simple - just unhiding few UI controls
> (context selection, organization crud pages).
>
>
> Each auto created resource would use organization assigned to its
> parent object (e.g. Discovered host would go to an organization
> based on its subnet's organization). This idea needs more detailed
> go-through.
>
> what happens when a subnet is shared across orgs?
>
> this is where the resource exists only in one org model breaks down when
> it comes to infrastructure, its perfectly fine for both orgs (QA and ENG
> for example) to share the same physical subnet, or same virtualization
> infrastructure.
>
>
> Isolation of organization: If everything belongs to a single
> organization and no names have global uniq names all is fine. When
> something is shared between organizations (useful for super-admins
> and power-users) it would make sense to allow editing of such
> resources only if user can edit them in all of the resource's
> organization. (e.g. resource R belonging to orgs A and B can be
> eddied only if user U has permission to edit R in both A and B
> orgs.) That would prevent accidental changes of shared resources. It
> would be also nice to mark all shared resources in UI with small
> icon or something.
>
> I think this could solve most or all the problems mentioned on the
> call, but I am maybe missing something, I'll appreciate any feedback.
>
>
> Defaulting to a forcing at least one default org is fine (just like we
> have for the admin user when auth is turned off), but I'm not sure it
> actually simplify anything (besides of adding more SQL), what we really
> want to do is to auto attach all resources (or turn off filtering) when
> there is only one org/location.

It simplifies the code, no more

if Setting['organizations_enabled']

do one thing

else

do another

end

It will always be just Resource.with_taxonomy_scope or something like
that. It will lower the complexity.

The more SQL concern seems to me like premature optimization, it'll only
add a condition to a query.

Yeah I think auto-assigning would be useful. I am not sure how you mean
'turn off filtering'?

···

On 13.05.14 13:18, Ohad Levy wrote: > On Fri, May 9, 2014 at 3:12 PM, Petr Chalupa > wrote:

Ohad
Petr



Marek: How does the new permission system behave in situation I've
described above? I think we talked about something similar but not
sure how it ended up implemented.

--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@__googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/__optout
<https://groups.google.com/d/optout>.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Petr_Chalupa · May 15, 2014, 9:03am

>
>
>
>
> Hi,
>
> sending my 2 cents:
>
> Everything should be assigned to at least one organization as suggested.
>
> Any Context should mean union of all your organization you can
> access. (It could also be allowed to select a subset of that.) (In
> code I would always tread context as collection of orgs and
> locations even if only one is selected. It should simplify the design.)
>
> All resources have uniq names in organization not globally (with
> exception Ohad mentioned). Auto disambiguation of resources could be
> put in place by automatically adding columns with organization and
> location into lists whenever more of them are selected.
>
> Foreman mode without organization would go away (big simplification
> of code base). Same functionality would be achieved by creating a
> default organization which would be always automatically used when
> Organization are disabled (same logic would work for users isolated
> into one organization only). Migration from disabled to enabled
> organizations would be simple - just unhiding few UI controls
> (context selection, organization crud pages).
>
>
> Each auto created resource would use organization assigned to its
> parent object (e.g. Discovered host would go to an organization
> based on its subnet's organization). This idea needs more detailed
> go-through.
>
> what happens when a subnet is shared across orgs?
>
> this is where the resource exists only in one org model breaks down when
> it comes to infrastructure, its perfectly fine for both orgs (QA and ENG
> for example) to share the same physical subnet, or same virtualization
> infrastructure.
>
>
> Isolation of organization: If everything belongs to a single
> organization and no names have global uniq names all is fine. When
> something is shared between organizations (useful for super-admins
> and power-users) it would make sense to allow editing of such
> resources only if user can edit them in all of the resource's
> organization. (e.g. resource R belonging to orgs A and B can be
> eddied only if user U has permission to edit R in both A and B
> orgs.) That would prevent accidental changes of shared resources. It
> would be also nice to mark all shared resources in UI with small
> icon or something.
>
> I think this could solve most or all the problems mentioned on the
> call, but I am maybe missing something, I'll appreciate any feedback.
>
>
> Defaulting to a forcing at least one default org is fine (just like we
> have for the admin user when auth is turned off), but I'm not sure it
> actually simplify anything (besides of adding more SQL), what we really
> want to do is to auto attach all resources (or turn off filtering) when
> there is only one org/location.