New permissions vs taxonomies

[Marek_Hulan]

Hello

new permissions get closer and closer to be merged, however there are some
other open PRs that change the way taxonomies work. It seems inevitable to
support displaying resources [1] from multiple taxonomies at the same time.
Unfortunately this breaks taxonomy support of filters.

Let me first briefly describe how new permissions were supposed to work. Role
has many filters. Filters has and belongs to many permissions. Permissions are
grouped by resource. Some resources supports granularity that enable you to
define limited filter using scope search syntax. During authorization you ask
for all objects of a particular resource for which user has a particular
permission. If there's any unlimited filter, you have this permission for all
objects of this resource, otherwise all limited filters are found, we create a
scoped_search condition by combining these filters with 'OR' and apply it using
search_for on this resource.

Currently we allow filters to be also related just to some taxonomies, so only
filters for current taxonomies would be applied. E.g. if you are in Israel
location and ask for hosts you can view, only filters from Israel location
would be found and applied.

When we support collections of objects from more taxonomies we can't apply
similar rule. Since we could end up in situation we found two filters each for
different organization and combine them with OR. For example it could allow
user to edit hosts from organization that he or she shouldn't be able to edit.
More information at [2]

So instead of setting taxonomy for filters we should set taxonomies for the
resources themselves using scoped_search (the condition string of filter). This
implies that we could apply taxonomies only on resources which includes
Taxonomix and support scoped search. It seems OK to me since there's not much
sense in granting e.g. viewing and editing of bookmarks only in one taxonomy
because you see all of them there.

Therefore filters wouldn't be searched based on current taxonomies but all of
them would be applied. More precisely all of those current user has assigned
through roles and contains particular permission. Taxonomies would be added to
filters searches like this "original_condition AND (organization = 1 AND
location = 2). Two or more filters are still combined by (F1) OR (F2). This
also implies that a filter that would have taxonomy set would become limited
automatically. Also assigning users to specific taxonomies no longer make sense
because you define objects they can work with by assigning them roles and
filters. I think taxonomies should be considered something like tags and
permissions should define which objects should I see by specifying these tags,
otherwise it seems as a second authorization system to me.

One drawback is that by scoped_search we can't easily say "for all current
user's organizations". One solution could be to dynamically modify conditions
for user by scoped search ext_method, but since authorization is done
frequently we should save as much time as possible. Second solution… well I
don't have second solution yet

So I'd like to have some input especially from Amos and Joseph since I think
you guys know most about taxonomies. I'd appreciate any input from others who
are interested. Also I'd like to split the knowledge of new permissions model
to other devs so we can discuss and find some solution in Belgium. …and I
don't want be the only one that will solve all the permission bugs

Not to forget, thanks Ivan and Ohad for pointing me to good directions, you're
definitely welcome in further discussions.

[1] by resource I mean objects like Hosts, Subnets, Domains, …
[2] suppose we have location Israel and sublocation Israel/TelAviv, one filter
for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now user
enters hosts index with current location set to Israel/TelAviv and we display
hosts from both locations (because of taxonomy inheritance), when we ask for
:edit_hosts permission we find and apply both filters (because of the same
reason) which grants :edit_hosts permission also for hosts in Israel which was
probably not intended. This is just one of example many cases why and how it
can fail.

···

-- Marek

[Bryan_Kearney]

> Hello
>
> new permissions get closer and closer to be merged, however there are some
> other open PRs that change the way taxonomies work. It seems inevitable to
> support displaying resources [1] from multiple taxonomies at the same time.
> Unfortunately this breaks taxonomy support of filters.
>
> Let me first briefly describe how new permissions were supposed to work. Role
> has many filters. Filters has and belongs to many permissions. Permissions are
> grouped by resource. Some resources supports granularity that enable you to
> define limited filter using scope search syntax. During authorization you ask
> for all objects of a particular resource for which user has a particular
> permission. If there's any unlimited filter, you have this permission for all
> objects of this resource, otherwise all limited filters are found, we create a
> scoped_search condition by combining these filters with 'OR' and apply it using
> search_for on this resource.
>
> Currently we allow filters to be also related just to some taxonomies, so only
> filters for current taxonomies would be applied. E.g. if you are in Israel
> location and ask for hosts you can view, only filters from Israel location
> would be found and applied.

Why not below? I would assume that I may be able to see isreal, bot not
see Data Center X in isreal.

I continue to think of taxonomies this way:

1. I look up to get default settings
2. I look down to see resources

Since filters apply to resources, I would assume I look down.

>
> When we support collections of objects from more taxonomies we can't apply
> similar rule. Since we could end up in situation we found two filters each for
> different organization and combine them with OR. For example it could allow
> user to edit hosts from organization that he or she shouldn't be able to edit.
> More information at [2]
>
> So instead of setting taxonomy for filters we should set taxonomies for the
> resources themselves using scoped_search (the condition string of filter). This
> implies that we could apply taxonomies only on resources which includes
> Taxonomix and support scoped search. It seems OK to me since there's not much
> sense in granting e.g. viewing and editing of bookmarks only in one taxonomy
> because you see all of them there.
>
> Therefore filters wouldn't be searched based on current taxonomies but all of
> them would be applied. More precisely all of those current user has assigned
> through roles and contains particular permission. Taxonomies would be added to
> filters searches like this "original_condition AND (organization = 1 AND
> location = 2). Two or more filters are still combined by (F1) OR (F2). This
> also implies that a filter that would have taxonomy set would become limited
> automatically. Also assigning users to specific taxonomies no longer make sense
> because you define objects they can work with by assigning them roles and
> filters. I think taxonomies should be considered something like tags and
> permissions should define which objects should I see by specifying these tags,
> otherwise it seems as a second authorization system to me.
>
> One drawback is that by scoped_search we can't easily say "for all current
> user's organizations". One solution could be to dynamically modify conditions
> for user by scoped search ext_method, but since authorization is done
> frequently we should save as much time as possible. Second solution… well I
> don't have second solution yet
>
> So I'd like to have some input especially from Amos and Joseph since I think
> you guys know most about taxonomies. I'd appreciate any input from others who
> are interested. Also I'd like to split the knowledge of new permissions model
> to other devs so we can discuss and find some solution in Belgium. …and I
> don't want be the only one that will solve all the permission bugs

i have to admit, at this point I am a bit lost

>
> Not to forget, thanks Ivan and Ohad for pointing me to good directions, you're
> definitely welcome in further discussions.
>
> [1] by resource I mean objects like Hosts, Subnets, Domains, …
> [2] suppose we have location Israel and sublocation Israel/TelAviv, one filter
> for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now user
> enters hosts index with current location set to Israel/TelAviv and we display
> hosts from both locations (because of taxonomy inheritance), when we ask for
> :edit_hosts permission we find and apply both filters (because of the same
> reason) which grants :edit_hosts permission also for hosts in Israel which was
> probably not intended. This is just one of example many cases why and how it
> can fail.

Yeah, I would not expect this. i would expect that the lower one only
grants access to edit in TelAviv.

– bk

···

On 01/23/2014 09:53 AM, Marek Hulan wrote:

[Joseph_Magen]

> From: "Marek Hulan" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, January 23, 2014 4:53:12 PM
> Subject: [foreman-dev] New permissions vs taxonomies
>
> Hello
>
> new permissions get closer and closer to be merged, however there are some
> other open PRs that change the way taxonomies work. It seems inevitable to
> support displaying resources [1] from multiple taxonomies at the same time.
> Unfortunately this breaks taxonomy support of filters.
>
> Let me first briefly describe how new permissions were supposed to work. Role
> has many filters. Filters has and belongs to many permissions. Permissions
> are
> grouped by resource. Some resources supports granularity that enable you to
> define limited filter using scope search syntax. During authorization you ask
> for all objects of a particular resource for which user has a particular
> permission. If there's any unlimited filter, you have this permission for all
> objects of this resource, otherwise all limited filters are found, we create
> a
> scoped_search condition by combining these filters with 'OR' and apply it
> using
> search_for on this resource.
>
> Currently we allow filters to be also related just to some taxonomies, so
> only
> filters for current taxonomies would be applied. E.g. if you are in Israel
> location and ask for hosts you can view, only filters from Israel location
> would be found and applied.
>
> When we support collections of objects from more taxonomies we can't apply
> similar rule. Since we could end up in situation we found two filters each
> for different organization and combine them with OR. For example it could allow
> user to edit hosts from organization that he or she shouldn't be able to
> edit.
> More information at [2]

When filtering by both location and organization, the filter should use AND, not OR. This is how it works for the default_scope "with_taxonomy_scope" for hostgroup, domain, subnet, smart proxy, etc.

In your situation, let's say a user can edit hosts in "Israel" location, but cannot edit hosts for "Payroll" organization. If the current location/organization is Israel/Payroll, then the user will NOT be able to edit hosts, since they need permission in both Israel AND Payroll.

I think taxonomies need to be treated specially with "AND" whereas all other filters use 'OR'.

>
> So instead of setting taxonomy for filters we should set taxonomies for the
> resources themselves using scoped_search (the condition string of filter).
> This
> implies that we could apply taxonomies only on resources which includes
> Taxonomix and support scoped search. It seems OK to me since there's not much
> sense in granting e.g. viewing and editing of bookmarks only in one taxonomy
> because you see all of them there.
>
> Therefore filters wouldn't be searched based on current taxonomies but all of
> them would be applied. More precisely all of those current user has assigned
> through roles and contains particular permission. Taxonomies would be added
> to
> filters searches like this "original_condition AND (organization = 1 AND
> location = 2). Two or more filters are still combined by (F1) OR (F2). This
> also implies that a filter that would have taxonomy set would become limited
> automatically. Also assigning users to specific taxonomies no longer make
> sense
> because you define objects they can work with by assigning them roles and
> filters. I think taxonomies should be considered something like tags and
> permissions should define which objects should I see by specifying these
> tags,
> otherwise it seems as a second authorization system to me.
>
> One drawback is that by scoped_search we can't easily say "for all current
> user's organizations". One solution could be to dynamically modify conditions
> for user by scoped search ext_method, but since authorization is done
> frequently we should save as much time as possible. Second solution… well I
> don't have second solution yet
>
> So I'd like to have some input especially from Amos and Joseph since I think
> you guys know most about taxonomies. I'd appreciate any input from others who
> are interested. Also I'd like to split the knowledge of new permissions model
> to other devs so we can discuss and find some solution in Belgium. …and I
> don't want be the only one that will solve all the permission bugs
>
> Not to forget, thanks Ivan and Ohad for pointing me to good directions,
> you're
> definitely welcome in further discussions.
>
> [1] by resource I mean objects like Hosts, Subnets, Domains, …
> [2] suppose we have location Israel and sublocation Israel/TelAviv, one
> filter
> for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now user
> enters hosts index with current location set to Israel/TelAviv and we display
> hosts from both locations (because of taxonomy inheritance), when we ask for
> :edit_hosts permission we find and apply both filters (because of the same
> reason) which grants :edit_hosts permission also for hosts in Israel which
> was
> probably not intended. This is just one of example many cases why and how it
> can fail.

The PR (https://github.com/theforeman/foreman/pull/1105) has changed since the deep dive demo. If current location is Israel/TelAviv, then user only sees hosts for Israel/TelAviv. If current location is Israel, then user sees hosts for Israel AND Israel/TelAviv. Only hosts in location Israel/TelAviv can be edited by user. Hosts in location Israel cannot. I think this works. Where is the conflict?

···

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

–
Marek

–
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/groups/opt_out.

[Petr_Chalupa]

> Hello
>
> new permissions get closer and closer to be merged, however there are some
> other open PRs that change the way taxonomies work. It seems inevitable to
> support displaying resources [1] from multiple taxonomies at the same time.
> Unfortunately this breaks taxonomy support of filters.
>
> Let me first briefly describe how new permissions were supposed to work. Role
> has many filters. Filters has and belongs to many permissions. Permissions are
> grouped by resource. Some resources supports granularity that enable you to
> define limited filter using scope search syntax. During authorization you ask
> for all objects of a particular resource for which user has a particular
> permission. If there's any unlimited filter, you have this permission for all
> objects of this resource, otherwise all limited filters are found, we create a
> scoped_search condition by combining these filters with 'OR' and apply it using
> search_for on this resource.
>
> Currently we allow filters to be also related just to some taxonomies, so only
> filters for current taxonomies would be applied. E.g. if you are in Israel
> location and ask for hosts you can view, only filters from Israel location
> would be found and applied.
>
> When we support collections of objects from more taxonomies we can't apply
> similar rule. Since we could end up in situation we found two filters each for
> different organization and combine them with OR. For example it could allow
> user to edit hosts from organization that he or she shouldn't be able to edit.
> More information at [2]
>
> So instead of setting taxonomy for filters we should set taxonomies for the
> resources themselves using scoped_search (the condition string of filter). This
> implies that we could apply taxonomies only on resources which includes
> Taxonomix and support scoped search. It seems OK to me since there's not much
> sense in granting e.g. viewing and editing of bookmarks only in one taxonomy
> because you see all of them there.
>
> Therefore filters wouldn't be searched based on current taxonomies but all of
> them would be applied. More precisely all of those current user has assigned
> through roles and contains particular permission. Taxonomies would be added to
> filters searches like this "original_condition AND (organization = 1 AND
> location = 2). Two or more filters are still combined by (F1) OR (F2). This
> also implies that a filter that would have taxonomy set would become limited
> automatically. Also assigning users to specific taxonomies no longer make sense
> because you define objects they can work with by assigning them roles and
> filters. I think taxonomies should be considered something like tags and
> permissions should define which objects should I see by specifying these tags,
> otherwise it seems as a second authorization system to me.
>
> One drawback is that by scoped_search we can't easily say "for all current
> user's organizations". One solution could be to dynamically modify conditions
> for user by scoped search ext_method, but since authorization is done
> frequently we should save as much time as possible. Second solution… well I
> don't have second solution yet

I've just talked with Marek and We might have a solution.

Let's assume that whenever something is not assigned to an organization
or a location it is like being assigned to all organizations and or
locations.

The User taxonomy would be considered as a part of permissions. An user
would not be ever able to access any data outside organizations or
locations assigned to him/her. This rule would be applied first.

Which means that any filter without taxonomy limits would be applied
only within this current-user's scope not globally as before.

E.g. an user belonging to org-1 and org2 having filter allowing him to
read all hosts would allow him to read only hosts from org-1 and org-2.

The queries for a given permission would look like this:

Let's assume that we are scoping the queries by given permission.

Let @orgs be an array of current organizations may be all users
organizations when "any context" is selected, or an array of one
currently selected organization (we could support multiple-choice
later). Let @locs meant the same for locations.

1. @filters = find all filters belonging to @orgs including parents AND
   @locs including parents.

2a. @filters includes an unlimited filter (no scoped search string) then
@resources = find all resources belonging to @orgs including parents AND
@locs including parents.

2b. @filters does not include unlimited filter then @resources = find
all resources belonging to @orgs including parents AND @locs including
parents AND @filtrers[0].condition AND … @filtrers[n].condition where
@filtrers[x].condition is a condition constructed by search_scope
including taxonomy conditions as described by Marek before
("original_scoped_search_condition AND (location = 1 OR location = 2)
AND (organization = 1 or organization = 2)")

This will allow to make general roles like Auditor (read only for all
resources). Auditor role would contain only filters without taxonomies
therefore it would apply in all current-users organizations.

Does it make sense?

Petr

···

On 23.01.14 15:53, Marek Hulan wrote:

So I’d like to have some input especially from Amos and Joseph since I think
you guys know most about taxonomies. I’d appreciate any input from others who
are interested. Also I’d like to split the knowledge of new permissions model
to other devs so we can discuss and find some solution in Belgium. …and I
don’t want be the only one that will solve all the permission bugs

Not to forget, thanks Ivan and Ohad for pointing me to good directions, you’re
definitely welcome in further discussions.

[1] by resource I mean objects like Hosts, Subnets, Domains, …
[2] suppose we have location Israel and sublocation Israel/TelAviv, one filter
for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now user
enters hosts index with current location set to Israel/TelAviv and we display
hosts from both locations (because of taxonomy inheritance), when we ask for
:edit_hosts permission we find and apply both filters (because of the same
reason) which grants :edit_hosts permission also for hosts in Israel which was
probably not intended. This is just one of example many cases why and how it
can fail.

[Marek_Hulan]

Thank you for reply Joseph. please see my answers below

>
> > From: "Marek Hulan" <mhulan@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, January 23, 2014 4:53:12 PM
> > Subject: [foreman-dev] New permissions vs taxonomies
> >
> > Hello
> >
> > new permissions get closer and closer to be merged, however there are some
> > other open PRs that change the way taxonomies work. It seems inevitable to
> > support displaying resources [1] from multiple taxonomies at the same
> > time.
> > Unfortunately this breaks taxonomy support of filters.
> >
> > Let me first briefly describe how new permissions were supposed to work.
> > Role has many filters. Filters has and belongs to many permissions.
> > Permissions are
> > grouped by resource. Some resources supports granularity that enable you
> > to
> > define limited filter using scope search syntax. During authorization you
> > ask for all objects of a particular resource for which user has a
> > particular permission. If there's any unlimited filter, you have this
> > permission for all objects of this resource, otherwise all limited
> > filters are found, we create a
> > scoped_search condition by combining these filters with 'OR' and apply it
> > using
> > search_for on this resource.
> >
> > Currently we allow filters to be also related just to some taxonomies, so
> > only
> > filters for current taxonomies would be applied. E.g. if you are in Israel
> > location and ask for hosts you can view, only filters from Israel location
> > would be found and applied.
> >
> > When we support collections of objects from more taxonomies we can't apply
> > similar rule. Since we could end up in situation we found two filters each
> > for different organization and combine them with OR. For example it could
> > allow user to edit hosts from organization that he or she shouldn't be
> > able to edit.
> > More information at [2]
>
> When filtering by both location and organization, the filter should use AND,
> not OR. This is how it works for the default_scope "with_taxonomy_scope"
> for hostgroup, domain, subnet, smart proxy, etc.
>
> In your situation, let's say a user can edit hosts in "Israel" location, but
> cannot edit hosts for "Payroll" organization. If the current
> location/organization is Israel/Payroll, then the user will NOT be able to
> edit hosts, since they need permission in both Israel AND Payroll.
>
> I think taxonomies need to be treated specially with "AND" whereas all other
> filters use 'OR'.

Agreed, I propose this in two paragraphs below. Just one nitpick for
clarification, if you select 2 or more taxonomies for filter they should be
combined by OR, like this

"original_scoped_search_condition AND (location = 1 OR location = 2) AND
(organization = 1 or organization = 2)

> > So instead of setting taxonomy for filters we should set taxonomies for
> > the
> > resources themselves using scoped_search (the condition string of filter).
> > This
> > implies that we could apply taxonomies only on resources which includes
> > Taxonomix and support scoped search. It seems OK to me since there's not
> > much sense in granting e.g. viewing and editing of bookmarks only in one
> > taxonomy because you see all of them there.
> >
> > Therefore filters wouldn't be searched based on current taxonomies but all
> > of them would be applied. More precisely all of those current user has
> > assigned through roles and contains particular permission. Taxonomies
> > would be added to
> > filters searches like this "original_condition AND (organization = 1 AND
> > location = 2). Two or more filters are still combined by (F1) OR (F2).
> > This
> > also implies that a filter that would have taxonomy set would become
> > limited automatically. Also assigning users to specific taxonomies no
> > longer make sense
> > because you define objects they can work with by assigning them roles and
> > filters. I think taxonomies should be considered something like tags and
> > permissions should define which objects should I see by specifying these
> > tags,
> > otherwise it seems as a second authorization system to me.
> >
> > One drawback is that by scoped_search we can't easily say "for all current
> > user's organizations". One solution could be to dynamically modify
> > conditions for user by scoped search ext_method, but since authorization
> > is done frequently we should save as much time as possible. Second
> > solution… well I don't have second solution yet
> >
> > So I'd like to have some input especially from Amos and Joseph since I
> > think you guys know most about taxonomies. I'd appreciate any input from
> > others who are interested. Also I'd like to split the knowledge of new
> > permissions model to other devs so we can discuss and find some solution
> > in Belgium. …and I don't want be the only one that will solve all the
> > permission bugs
> >
> > Not to forget, thanks Ivan and Ohad for pointing me to good directions,
> > you're
> > definitely welcome in further discussions.
> >
> > [1] by resource I mean objects like Hosts, Subnets, Domains, …
> > [2] suppose we have location Israel and sublocation Israel/TelAviv, one
> > filter
> > for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now
> > user enters hosts index with current location set to Israel/TelAviv and
> > we display hosts from both locations (because of taxonomy inheritance),
> > when we ask for>
> > :edit_hosts permission we find and apply both filters (because of the same
> >
> > reason) which grants :edit_hosts permission also for hosts in Israel which
> > was
> > probably not intended. This is just one of example many cases why and how
> > it can fail.
>
> The PR (https://github.com/theforeman/foreman/pull/1105) has changed since
> the deep dive demo. If current location is Israel/TelAviv, then user only
> sees hosts for Israel/TelAviv. If current location is Israel, then user
> sees hosts for Israel AND Israel/TelAviv. Only hosts in location
> Israel/TelAviv can be edited by user. Hosts in location Israel cannot. I
> think this works. Where is the conflict?

Ok in this case we have different problem. Assume we have two filters both for
viewing hosts:
Filter 1 with search 'domain = example.com' with location set to Israel
Filter 2 unlimited with location set to Israel/TelAviv
User selects Israel as current location and goes to hosts index so we ask for
all hosts that user can view.

We search for all filters (using same rules as for hosts) that grants
:view_host permission and because of inheritance we find both filters. Now we
ask, is there any filter that is unlimited? Answer is yes, therefore we do not
perform further filtering and display all hosts from Israel and Israel/TelAviv.
User will see hosts assigned to Israel location with domain = 'secret.org'.

What I proposed is not to use same taxonomy logic for filters. I think instead
of filters relations to taxonomies we should add these to scoped_search
conditions. Therefore every filter with defined taxonomy would be limited.

One difference with this solution is that we can't say "all hosts within all
users locations" in scoped search, which was supposed to work by not setting
any taxonomy to filter before taxonomy inheritance. However there should be a
solution using ext_method for scoped search.

Does it make sense?

···

On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: > ----- Original Message -----

–
Marek

–
Marek

–
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/groups/opt_out.

[Joseph_Magen]

My reply below

> From: "Marek Hulan" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Monday, January 27, 2014 10:55:03 AM
> Subject: Re: [foreman-dev] New permissions vs taxonomies
>
> Thank you for reply Joseph. please see my answers below
>
> >
> > > From: "Marek Hulan" <mhulan@redhat.com>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Thursday, January 23, 2014 4:53:12 PM
> > > Subject: [foreman-dev] New permissions vs taxonomies
> > >
> > > Hello
> > >
> > > new permissions get closer and closer to be merged, however there are
> > > some
> > > other open PRs that change the way taxonomies work. It seems inevitable
> > > to
> > > support displaying resources [1] from multiple taxonomies at the same
> > > time.
> > > Unfortunately this breaks taxonomy support of filters.
> > >
> > > Let me first briefly describe how new permissions were supposed to work.
> > > Role has many filters. Filters has and belongs to many permissions.
> > > Permissions are
> > > grouped by resource. Some resources supports granularity that enable you
> > > to
> > > define limited filter using scope search syntax. During authorization you
> > > ask for all objects of a particular resource for which user has a
> > > particular permission. If there's any unlimited filter, you have this
> > > permission for all objects of this resource, otherwise all limited
> > > filters are found, we create a
> > > scoped_search condition by combining these filters with 'OR' and apply it
> > > using
> > > search_for on this resource.
> > >
> > > Currently we allow filters to be also related just to some taxonomies, so
> > > only
> > > filters for current taxonomies would be applied. E.g. if you are in
> > > Israel
> > > location and ask for hosts you can view, only filters from Israel
> > > location
> > > would be found and applied.
> > >
> > > When we support collections of objects from more taxonomies we can't
> > > apply
> > > similar rule. Since we could end up in situation we found two filters
> > > each
> > > for different organization and combine them with OR. For example it could
> > > allow user to edit hosts from organization that he or she shouldn't be
> > > able to edit.
> > > More information at [2]
> >
> > When filtering by both location and organization, the filter should use
> > AND,
> > not OR. This is how it works for the default_scope "with_taxonomy_scope"
> > for hostgroup, domain, subnet, smart proxy, etc.
> >
> > In your situation, let's say a user can edit hosts in "Israel" location,
> > but
> > cannot edit hosts for "Payroll" organization. If the current
> > location/organization is Israel/Payroll, then the user will NOT be able to
> > edit hosts, since they need permission in both Israel AND Payroll.
> >
> > I think taxonomies need to be treated specially with "AND" whereas all
> > other
> > filters use 'OR'.
>
> Agreed, I propose this in two paragraphs below. Just one nitpick for
> clarification, if you select 2 or more taxonomies for filter they should be
> combined by OR, like this
>
> "original_scoped_search_condition AND (location = 1 OR location = 2) AND
> (organization = 1 or organization = 2)
>

Yes, this makes sense.

> > > So instead of setting taxonomy for filters we should set taxonomies for
> > > the
> > > resources themselves using scoped_search (the condition string of
> > > filter).
> > > This
> > > implies that we could apply taxonomies only on resources which includes
> > > Taxonomix and support scoped search. It seems OK to me since there's not
> > > much sense in granting e.g. viewing and editing of bookmarks only in one
> > > taxonomy because you see all of them there.
> > >
> > > Therefore filters wouldn't be searched based on current taxonomies but
> > > all
> > > of them would be applied. More precisely all of those current user has
> > > assigned through roles and contains particular permission. Taxonomies
> > > would be added to
> > > filters searches like this "original_condition AND (organization = 1 AND
> > > location = 2). Two or more filters are still combined by (F1) OR (F2).
> > > This
> > > also implies that a filter that would have taxonomy set would become
> > > limited automatically. Also assigning users to specific taxonomies no
> > > longer make sense
> > > because you define objects they can work with by assigning them roles and
> > > filters. I think taxonomies should be considered something like tags and
> > > permissions should define which objects should I see by specifying these
> > > tags,
> > > otherwise it seems as a second authorization system to me.
> > >
> > > One drawback is that by scoped_search we can't easily say "for all
> > > current
> > > user's organizations". One solution could be to dynamically modify
> > > conditions for user by scoped search ext_method, but since authorization
> > > is done frequently we should save as much time as possible. Second
> > > solution… well I don't have second solution yet
> > >
> > > So I'd like to have some input especially from Amos and Joseph since I
> > > think you guys know most about taxonomies. I'd appreciate any input from
> > > others who are interested. Also I'd like to split the knowledge of new
> > > permissions model to other devs so we can discuss and find some solution
> > > in Belgium. …and I don't want be the only one that will solve all the
> > > permission bugs
> > >
> > > Not to forget, thanks Ivan and Ohad for pointing me to good directions,
> > > you're
> > > definitely welcome in further discussions.
> > >
> > > [1] by resource I mean objects like Hosts, Subnets, Domains, …
> > > [2] suppose we have location Israel and sublocation Israel/TelAviv, one
> > > filter
> > > for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv, now
> > > user enters hosts index with current location set to Israel/TelAviv and
> > > we display hosts from both locations (because of taxonomy inheritance),
> > > when we ask for>
> > > :edit_hosts permission we find and apply both filters (because of the
> > > same
> > >
> > > reason) which grants :edit_hosts permission also for hosts in Israel
> > > which
> > > was
> > > probably not intended. This is just one of example many cases why and how
> > > it can fail.
> >
> > The PR (https://github.com/theforeman/foreman/pull/1105) has changed since
> > the deep dive demo. If current location is Israel/TelAviv, then user only
> > sees hosts for Israel/TelAviv. If current location is Israel, then user
> > sees hosts for Israel AND Israel/TelAviv. Only hosts in location
> > Israel/TelAviv can be edited by user. Hosts in location Israel cannot. I
> > think this works. Where is the conflict?
>
> Ok in this case we have different problem. Assume we have two filters both
> for
> viewing hosts:
> Filter 1 with search 'domain = example.com' with location set to Israel
> Filter 2 unlimited with location set to Israel/TelAviv
> User selects Israel as current location and goes to hosts index so we ask for
> all hosts that user can view.
>
> We search for all filters (using same rules as for hosts) that grants
> :view_host permission and because of inheritance we find both filters.

No, we now wouldn't find both filters. This is how it was in my demo, but now it's not. For viewing, you see the current location and it's children (descendents), not its parents (ancestors).
So, in your example, the user only has permission to see hosts in Israel/TelAviv, not in all Israel, so the list will be limited to only Israel/TelAviv. Again, it wasn't like this in my demo which is probably the source of confusion.

> Now we
> ask, is there any filter that is unlimited? Answer is yes, therefore we do
> not
> perform further filtering and display all hosts from Israel and
> Israel/TelAviv.
> User will see hosts assigned to Israel location with domain = 'secret.org'.

If you use the logic you mentioned above "original_scoped_search_condition AND (location = 1 OR location = 2)"
then it would be 'domain = example.com' AND location = 'Israel/TelAviv'
This would not show hosts with domain = 'secret.org'

>
> What I proposed is not to use same taxonomy logic for filters. I think
> instead
> of filters relations to taxonomies we should add these to scoped_search
> conditions. Therefore every filter with defined taxonomy would be limited.

Yes, this makes sense.

>
> One difference with this solution is that we can't say "all hosts within all
> users locations" in scoped search, which was supposed to work by not setting
> any taxonomy to filter before taxonomy inheritance. However there should be a
> solution using ext_method for scoped search.

I think this will still work to have "all hosts within all users locations" as long as it satisfies the current organization and other all others filters. With inheritance, it would now be "all user locations and descendants of locations" (not ancestors).

Another area of confusion is that hosts are different than all other objects, since only hosts have one location and one organization explicitly assigned. The other objects (domain, hostgroup, etc) have a many-to-many relationship with locations/organizations.

I agree that there can be collisions of filters. In these cases, I would take the 'pessimistic' view and not allow.

Regards,

Joseph

···

----- Original Message ----- > On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: > > ----- Original Message -----

Does it make sense?

–
Marek

–
Marek

–
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/groups/opt_out.

–
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/groups/opt_out.

[Marek_Hulan]

Comments in text below

> My reply below
>
>
> > From: "Marek Hulan" <mhulan@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Monday, January 27, 2014 10:55:03 AM
> > Subject: Re: [foreman-dev] New permissions vs taxonomies
> >
> > Thank you for reply Joseph. please see my answers below
> >
> > >
> > > > From: "Marek Hulan" <mhulan@redhat.com>
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Thursday, January 23, 2014 4:53:12 PM
> > > > Subject: [foreman-dev] New permissions vs taxonomies
> > > >
> > > > Hello
> > > >
> > > > new permissions get closer and closer to be merged, however there are
> > > > some
> > > > other open PRs that change the way taxonomies work. It seems
> > > > inevitable
> > > > to
> > > > support displaying resources [1] from multiple taxonomies at the same
> > > > time.
> > > > Unfortunately this breaks taxonomy support of filters.
> > > >
> > > > Let me first briefly describe how new permissions were supposed to
> > > > work.
> > > > Role has many filters. Filters has and belongs to many permissions.
> > > > Permissions are
> > > > grouped by resource. Some resources supports granularity that enable
> > > > you
> > > > to
> > > > define limited filter using scope search syntax. During authorization
> > > > you
> > > > ask for all objects of a particular resource for which user has a
> > > > particular permission. If there's any unlimited filter, you have this
> > > > permission for all objects of this resource, otherwise all limited
> > > > filters are found, we create a
> > > > scoped_search condition by combining these filters with 'OR' and apply
> > > > it
> > > > using
> > > > search_for on this resource.
> > > >
> > > > Currently we allow filters to be also related just to some taxonomies,
> > > > so
> > > > only
> > > > filters for current taxonomies would be applied. E.g. if you are in
> > > > Israel
> > > > location and ask for hosts you can view, only filters from Israel
> > > > location
> > > > would be found and applied.
> > > >
> > > > When we support collections of objects from more taxonomies we can't
> > > > apply
> > > > similar rule. Since we could end up in situation we found two filters
> > > > each
> > > > for different organization and combine them with OR. For example it
> > > > could
> > > > allow user to edit hosts from organization that he or she shouldn't be
> > > > able to edit.
> > > > More information at [2]
> > >
> > > When filtering by both location and organization, the filter should use
> > > AND,
> > > not OR. This is how it works for the default_scope
> > > "with_taxonomy_scope"
> > > for hostgroup, domain, subnet, smart proxy, etc.
> > >
> > > In your situation, let's say a user can edit hosts in "Israel" location,
> > > but
> > > cannot edit hosts for "Payroll" organization. If the current
> > > location/organization is Israel/Payroll, then the user will NOT be able
> > > to
> > > edit hosts, since they need permission in both Israel AND Payroll.
> > >
> > > I think taxonomies need to be treated specially with "AND" whereas all
> > > other
> > > filters use 'OR'.
> >
> > Agreed, I propose this in two paragraphs below. Just one nitpick for
> > clarification, if you select 2 or more taxonomies for filter they should
> > be
> > combined by OR, like this
> >
> > "original_scoped_search_condition AND (location = 1 OR location = 2) AND
> > (organization = 1 or organization = 2)
>
> Yes, this makes sense.
>
> > > > So instead of setting taxonomy for filters we should set taxonomies
> > > > for
> > > > the
> > > > resources themselves using scoped_search (the condition string of
> > > > filter).
> > > > This
> > > > implies that we could apply taxonomies only on resources which
> > > > includes
> > > > Taxonomix and support scoped search. It seems OK to me since there's
> > > > not
> > > > much sense in granting e.g. viewing and editing of bookmarks only in
> > > > one
> > > > taxonomy because you see all of them there.
> > > >
> > > > Therefore filters wouldn't be searched based on current taxonomies but
> > > > all
> > > > of them would be applied. More precisely all of those current user has
> > > > assigned through roles and contains particular permission. Taxonomies
> > > > would be added to
> > > > filters searches like this "original_condition AND (organization = 1
> > > > AND
> > > > location = 2). Two or more filters are still combined by (F1) OR (F2).
> > > > This
> > > > also implies that a filter that would have taxonomy set would become
> > > > limited automatically. Also assigning users to specific taxonomies no
> > > > longer make sense
> > > > because you define objects they can work with by assigning them roles
> > > > and
> > > > filters. I think taxonomies should be considered something like tags
> > > > and
> > > > permissions should define which objects should I see by specifying
> > > > these
> > > > tags,
> > > > otherwise it seems as a second authorization system to me.
> > > >
> > > > One drawback is that by scoped_search we can't easily say "for all
> > > > current
> > > > user's organizations". One solution could be to dynamically modify
> > > > conditions for user by scoped search ext_method, but since
> > > > authorization
> > > > is done frequently we should save as much time as possible. Second
> > > > solution… well I don't have second solution yet
> > > >
> > > > So I'd like to have some input especially from Amos and Joseph since I
> > > > think you guys know most about taxonomies. I'd appreciate any input
> > > > from
> > > > others who are interested. Also I'd like to split the knowledge of new
> > > > permissions model to other devs so we can discuss and find some
> > > > solution
> > > > in Belgium. …and I don't want be the only one that will solve all
> > > > the
> > > > permission bugs
> > > >
> > > > Not to forget, thanks Ivan and Ohad for pointing me to good
> > > > directions,
> > > > you're
> > > > definitely welcome in further discussions.
> > > >
> > > > [1] by resource I mean objects like Hosts, Subnets, Domains, …
> > > > [2] suppose we have location Israel and sublocation Israel/TelAviv,
> > > > one
> > > > filter
> > > > for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv,
> > > > now
> > > > user enters hosts index with current location set to Israel/TelAviv
> > > > and
> > > > we display hosts from both locations (because of taxonomy
> > > > inheritance),
> > > > when we ask for>
> > > >
> > > > :edit_hosts permission we find and apply both filters (because of the
> > > >
> > > > same
> > > >
> > > > reason) which grants :edit_hosts permission also for hosts in Israel
> > > > which
> > > > was
> > > > probably not intended. This is just one of example many cases why and
> > > > how
> > > > it can fail.
> > >
> > > The PR (https://github.com/theforeman/foreman/pull/1105) has changed
> > > since
> > > the deep dive demo. If current location is Israel/TelAviv, then user
> > > only
> > > sees hosts for Israel/TelAviv. If current location is Israel, then user
> > > sees hosts for Israel AND Israel/TelAviv. Only hosts in location
> > > Israel/TelAviv can be edited by user. Hosts in location Israel cannot.
> > > I
> > > think this works. Where is the conflict?
> >
> > Ok in this case we have different problem. Assume we have two filters both
> > for
> > viewing hosts:
> > Filter 1 with search 'domain = example.com' with location set to Israel
> > Filter 2 unlimited with location set to Israel/TelAviv
> > User selects Israel as current location and goes to hosts index so we ask
> > for all hosts that user can view.
> >
> > We search for all filters (using same rules as for hosts) that grants
> >
> > :view_host permission and because of inheritance we find both filters.
>
> No, we now wouldn't find both filters. This is how it was in my demo, but
> now it's not. For viewing, you see the current location and it's children
> (descendents), not its parents (ancestors). So, in your example, the user
> only has permission to see hosts in Israel/TelAviv, not in all Israel, so
> the list will be limited to only Israel/TelAviv. Again, it wasn't like
> this in my demo which is probably the source of confusion.

Ok, sorry you're right. But the same problem exists just in mirror example.
You're in Israel and since inheritance now works for descendants, filters from
Israel/TelAviv would be found. Therefore you would have unlimited filter from
Israel/TelAviv applied on Israel hosts.

> > Now we
> > ask, is there any filter that is unlimited? Answer is yes, therefore we do
> > not
> > perform further filtering and display all hosts from Israel and
> > Israel/TelAviv.
> > User will see hosts assigned to Israel location with domain =
> > 'secret.org'.
>
> If you use the logic you mentioned above "original_scoped_search_condition
> AND (location = 1 OR location = 2)" then it would be 'domain = example.com'
> AND location = 'Israel/TelAviv' This would not show hosts with domain =
> 'secret.org'

Yes with proposed change - taxonomies would be part of scoped search - no more
issues with mixing unlimited filters. This also means that a given filter
applies just to objects assigned to those taxonomies.
>
> > What I proposed is not to use same taxonomy logic for filters. I think
> > instead
> > of filters relations to taxonomies we should add these to scoped_search
> > conditions. Therefore every filter with defined taxonomy would be limited.
>
> Yes, this makes sense.
>
> > One difference with this solution is that we can't say "all hosts within
> > all users locations" in scoped search, which was supposed to work by not
> > setting any taxonomy to filter before taxonomy inheritance. However there
> > should be a solution using ext_method for scoped search.
>
> I think this will still work to have "all hosts within all users locations"
> as long as it satisfies the current organization and other all others
> filters. With inheritance, it would now be "all user locations and
> descendants of locations" (not ancestors).
>
> Another area of confusion is that hosts are different than all other
> objects, since only hosts have one location and one organization explicitly
> assigned. The other objects (domain, hostgroup, etc) have a many-to-many
> relationship with locations/organizations.
>
> I agree that there can be collisions of filters. In these cases, I would
> take the 'pessimistic' view and not allow.

If I understand correctly, the problem would be when e.g. domain is assigned
to two orgs at the same time and there are two filters that would grant some
permission like edit where 'name ~ foo*' and second 'name ~ bar', each set for
one organization.

In this case both filters would be found and joined by 'OR' which is correct I
think. It allows you to modify domains from particular org which satisfy name
condition and it should not matter which org you have currently selected. Or
would it be to confusing for users?

···

On Monday 27 of January 2014 05:42:19 Joseph Magen wrote: > ----- Original Message ----- > > On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: > > > ----- Original Message -----

–
Marek

[Joseph_Magen]

My comments below.

> From: "Marek Hulan" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, January 29, 2014 11:55:15 AM
> Subject: Re: [foreman-dev] New permissions vs taxonomies
>
> Comments in text below
>
> > My reply below
> >
> >
> > > From: "Marek Hulan" <mhulan@redhat.com>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Monday, January 27, 2014 10:55:03 AM
> > > Subject: Re: [foreman-dev] New permissions vs taxonomies
> > >
> > > Thank you for reply Joseph. please see my answers below
> > >
> > > >
> > > > > From: "Marek Hulan" <mhulan@redhat.com>
> > > > > To: foreman-dev@googlegroups.com
> > > > > Sent: Thursday, January 23, 2014 4:53:12 PM
> > > > > Subject: [foreman-dev] New permissions vs taxonomies
> > > > >
> > > > > Hello
> > > > >
> > > > > new permissions get closer and closer to be merged, however there are
> > > > > some
> > > > > other open PRs that change the way taxonomies work. It seems
> > > > > inevitable
> > > > > to
> > > > > support displaying resources [1] from multiple taxonomies at the same
> > > > > time.
> > > > > Unfortunately this breaks taxonomy support of filters.
> > > > >
> > > > > Let me first briefly describe how new permissions were supposed to
> > > > > work.
> > > > > Role has many filters. Filters has and belongs to many permissions.
> > > > > Permissions are
> > > > > grouped by resource. Some resources supports granularity that enable
> > > > > you
> > > > > to
> > > > > define limited filter using scope search syntax. During authorization
> > > > > you
> > > > > ask for all objects of a particular resource for which user has a
> > > > > particular permission. If there's any unlimited filter, you have this
> > > > > permission for all objects of this resource, otherwise all limited
> > > > > filters are found, we create a
> > > > > scoped_search condition by combining these filters with 'OR' and
> > > > > apply
> > > > > it
> > > > > using
> > > > > search_for on this resource.
> > > > >
> > > > > Currently we allow filters to be also related just to some
> > > > > taxonomies,
> > > > > so
> > > > > only
> > > > > filters for current taxonomies would be applied. E.g. if you are in
> > > > > Israel
> > > > > location and ask for hosts you can view, only filters from Israel
> > > > > location
> > > > > would be found and applied.
> > > > >
> > > > > When we support collections of objects from more taxonomies we can't
> > > > > apply
> > > > > similar rule. Since we could end up in situation we found two filters
> > > > > each
> > > > > for different organization and combine them with OR. For example it
> > > > > could
> > > > > allow user to edit hosts from organization that he or she shouldn't
> > > > > be
> > > > > able to edit.
> > > > > More information at [2]
> > > >
> > > > When filtering by both location and organization, the filter should use
> > > > AND,
> > > > not OR. This is how it works for the default_scope
> > > > "with_taxonomy_scope"
> > > > for hostgroup, domain, subnet, smart proxy, etc.
> > > >
> > > > In your situation, let's say a user can edit hosts in "Israel"
> > > > location,
> > > > but
> > > > cannot edit hosts for "Payroll" organization. If the current
> > > > location/organization is Israel/Payroll, then the user will NOT be able
> > > > to
> > > > edit hosts, since they need permission in both Israel AND Payroll.
> > > >
> > > > I think taxonomies need to be treated specially with "AND" whereas all
> > > > other
> > > > filters use 'OR'.
> > >
> > > Agreed, I propose this in two paragraphs below. Just one nitpick for
> > > clarification, if you select 2 or more taxonomies for filter they should
> > > be
> > > combined by OR, like this
> > >
> > > "original_scoped_search_condition AND (location = 1 OR location = 2) AND
> > > (organization = 1 or organization = 2)
> >
> > Yes, this makes sense.
> >
> > > > > So instead of setting taxonomy for filters we should set taxonomies
> > > > > for
> > > > > the
> > > > > resources themselves using scoped_search (the condition string of
> > > > > filter).
> > > > > This
> > > > > implies that we could apply taxonomies only on resources which
> > > > > includes
> > > > > Taxonomix and support scoped search. It seems OK to me since there's
> > > > > not
> > > > > much sense in granting e.g. viewing and editing of bookmarks only in
> > > > > one
> > > > > taxonomy because you see all of them there.
> > > > >
> > > > > Therefore filters wouldn't be searched based on current taxonomies
> > > > > but
> > > > > all
> > > > > of them would be applied. More precisely all of those current user
> > > > > has
> > > > > assigned through roles and contains particular permission. Taxonomies
> > > > > would be added to
> > > > > filters searches like this "original_condition AND (organization = 1
> > > > > AND
> > > > > location = 2). Two or more filters are still combined by (F1) OR
> > > > > (F2).
> > > > > This
> > > > > also implies that a filter that would have taxonomy set would become
> > > > > limited automatically. Also assigning users to specific taxonomies no
> > > > > longer make sense
> > > > > because you define objects they can work with by assigning them roles
> > > > > and
> > > > > filters. I think taxonomies should be considered something like tags
> > > > > and
> > > > > permissions should define which objects should I see by specifying
> > > > > these
> > > > > tags,
> > > > > otherwise it seems as a second authorization system to me.
> > > > >
> > > > > One drawback is that by scoped_search we can't easily say "for all
> > > > > current
> > > > > user's organizations". One solution could be to dynamically modify
> > > > > conditions for user by scoped search ext_method, but since
> > > > > authorization
> > > > > is done frequently we should save as much time as possible. Second
> > > > > solution… well I don't have second solution yet
> > > > >
> > > > > So I'd like to have some input especially from Amos and Joseph since
> > > > > I
> > > > > think you guys know most about taxonomies. I'd appreciate any input
> > > > > from
> > > > > others who are interested. Also I'd like to split the knowledge of
> > > > > new
> > > > > permissions model to other devs so we can discuss and find some
> > > > > solution
> > > > > in Belgium. …and I don't want be the only one that will solve all
> > > > > the
> > > > > permission bugs
> > > > >
> > > > > Not to forget, thanks Ivan and Ohad for pointing me to good
> > > > > directions,
> > > > > you're
> > > > > definitely welcome in further discussions.
> > > > >
> > > > > [1] by resource I mean objects like Hosts, Subnets, Domains, …
> > > > > [2] suppose we have location Israel and sublocation Israel/TelAviv,
> > > > > one
> > > > > filter
> > > > > for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv,
> > > > > now
> > > > > user enters hosts index with current location set to Israel/TelAviv
> > > > > and
> > > > > we display hosts from both locations (because of taxonomy
> > > > > inheritance),
> > > > > when we ask for>
> > > > >
> > > > > :edit_hosts permission we find and apply both filters (because of the
> > > > >
> > > > > same
> > > > >
> > > > > reason) which grants :edit_hosts permission also for hosts in Israel
> > > > > which
> > > > > was
> > > > > probably not intended. This is just one of example many cases why and
> > > > > how
> > > > > it can fail.
> > > >
> > > > The PR (https://github.com/theforeman/foreman/pull/1105) has changed
> > > > since
> > > > the deep dive demo. If current location is Israel/TelAviv, then user
> > > > only
> > > > sees hosts for Israel/TelAviv. If current location is Israel, then
> > > > user
> > > > sees hosts for Israel AND Israel/TelAviv. Only hosts in location
> > > > Israel/TelAviv can be edited by user. Hosts in location Israel cannot.
> > > > I
> > > > think this works. Where is the conflict?
> > >
> > > Ok in this case we have different problem. Assume we have two filters
> > > both
> > > for
> > > viewing hosts:
> > > Filter 1 with search 'domain = example.com' with location set to Israel
> > > Filter 2 unlimited with location set to Israel/TelAviv
> > > User selects Israel as current location and goes to hosts index so we ask
> > > for all hosts that user can view.
> > >
> > > We search for all filters (using same rules as for hosts) that grants
> > >
> > > :view_host permission and because of inheritance we find both filters.
> >
> > No, we now wouldn't find both filters. This is how it was in my demo, but
> > now it's not. For viewing, you see the current location and it's children
> > (descendents), not its parents (ancestors). So, in your example, the user
> > only has permission to see hosts in Israel/TelAviv, not in all Israel, so
> > the list will be limited to only Israel/TelAviv. Again, it wasn't like
> > this in my demo which is probably the source of confusion.
>
> Ok, sorry you're right. But the same problem exists just in mirror example.
> You're in Israel and since inheritance now works for descendants, filters
> from
> Israel/TelAviv would be found. Therefore you would have unlimited filter from
> Israel/TelAviv applied on Israel hosts.

What do you mean by unlimited filter? If I understand correctly, we need to allow high level filters to override low-level filters.

For example:

• CEO can see all hosts in Israel.
• Tel Aviv sysadmin can allow see hosts in Israel/Tel Aviv
• CEO cannot see hosts in Israel/Tel Aviv ('bad filter')

Now there is a collision when location is Israel. One filter says CEO can see hosts. Another 'bad filter' says CEO cannot see hosts in Tel Aviv.

In this trivial example, I would say that the top-level permission 'wins' and allow the CEO to see hosts in Tel Aviv.

In code, it's not a matter of combining filters with AND or OR but rather overriding/ignoring some of them that are 'lower' priority.

>
> > > Now we
> > > ask, is there any filter that is unlimited? Answer is yes, therefore we
> > > do
> > > not
> > > perform further filtering and display all hosts from Israel and
> > > Israel/TelAviv.
> > > User will see hosts assigned to Israel location with domain =
> > > 'secret.org'.
> >
> > If you use the logic you mentioned above "original_scoped_search_condition
> > AND (location = 1 OR location = 2)" then it would be 'domain = example.com'
> > AND location = 'Israel/TelAviv' This would not show hosts with domain =
> > 'secret.org'
>
> Yes with proposed change - taxonomies would be part of scoped search - no
> more
> issues with mixing unlimited filters. This also means that a given filter
> applies just to objects assigned to those taxonomies.

Yes, taxonomies are currently part of scoped search. All objects that can be assigned to a taxonomy have a default scope called 'with_taxonomy_scope'

> >
> > > What I proposed is not to use same taxonomy logic for filters. I think
> > > instead
> > > of filters relations to taxonomies we should add these to scoped_search
> > > conditions. Therefore every filter with defined taxonomy would be
> > > limited.
> >
> > Yes, this makes sense.
> >
> > > One difference with this solution is that we can't say "all hosts within
> > > all users locations" in scoped search, which was supposed to work by not
> > > setting any taxonomy to filter before taxonomy inheritance. However there
> > > should be a solution using ext_method for scoped search.
> >
> > I think this will still work to have "all hosts within all users locations"
> > as long as it satisfies the current organization and other all others
> > filters. With inheritance, it would now be "all user locations and
> > descendants of locations" (not ancestors).
> >
> > Another area of confusion is that hosts are different than all other
> > objects, since only hosts have one location and one organization explicitly
> > assigned. The other objects (domain, hostgroup, etc) have a many-to-many
> > relationship with locations/organizations.
> >
> > I agree that there can be collisions of filters. In these cases, I would
> > take the 'pessimistic' view and not allow.
>
> If I understand correctly, the problem would be when e.g. domain is assigned
> to two orgs at the same time and there are two filters that would grant some
> permission like edit where 'name ~ foo*' and second 'name ~ bar', each set
> for
> one organization.

Are you allowing name ~ foo* no matter which is the current organization or name ~foo* only within the current organization.
It's a big difference - AND or OR
Or maybe you are offering both options?

···

----- Original Message ----- > On Monday 27 of January 2014 05:42:19 Joseph Magen wrote: > > ----- Original Message ----- > > > On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: > > > > ----- Original Message -----

In this case both filters would be found and joined by ‘OR’ which is correct
I
think. It allows you to modify domains from particular org which satisfy name
condition and it should not matter which org you have currently selected. Or
would it be to confusing for users?

–
Marek

–
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/groups/opt_out.

[Bryan_Kearney]

I had always preferred the simple model… even if it makes it less
powerful. So… OR everything. If that means you did not want the CEO to
see tings in Tel Aviv you would be force to put more rules out there.

– bk

···

On 01/29/2014 05:20 AM, Joseph Magen wrote: > What do you mean by unlimited filter? If I understand correctly, we need to allow high level filters to override low-level filters. > > For example: > * CEO can see all hosts in Israel. > * Tel Aviv sysadmin can allow see hosts in Israel/Tel Aviv > * CEO cannot see hosts in Israel/Tel Aviv ('bad filter') > > Now there is a collision when location is Israel. One filter says CEO can see hosts. Another 'bad filter' says CEO cannot see hosts in Tel Aviv. > > In this trivial example, I would say that the top-level permission 'wins' and allow the CEO to see hosts in Tel Aviv. > > In code, it's not a matter of combining filters with AND or OR but rather overriding/ignoring some of them that are 'lower' priority.

[Petr_Chalupa]

> My comments below.
>
>> From: "Marek Hulan" <mhulan@redhat.com>
>> To: foreman-dev@googlegroups.com
>> Sent: Wednesday, January 29, 2014 11:55:15 AM
>> Subject: Re: [foreman-dev] New permissions vs taxonomies
>>
>> Comments in text below
>>
>>> My reply below
>>>
>>>
>>>> From: "Marek Hulan" <mhulan@redhat.com>
>>>> To: foreman-dev@googlegroups.com
>>>> Sent: Monday, January 27, 2014 10:55:03 AM
>>>> Subject: Re: [foreman-dev] New permissions vs taxonomies
>>>>
>>>> Thank you for reply Joseph. please see my answers below
>>>>
>>>>>
>>>>>> From: "Marek Hulan" <mhulan@redhat.com>
>>>>>> To: foreman-dev@googlegroups.com
>>>>>> Sent: Thursday, January 23, 2014 4:53:12 PM
>>>>>> Subject: [foreman-dev] New permissions vs taxonomies
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> new permissions get closer and closer to be merged, however there are
>>>>>> some
>>>>>> other open PRs that change the way taxonomies work. It seems
>>>>>> inevitable
>>>>>> to
>>>>>> support displaying resources [1] from multiple taxonomies at the same
>>>>>> time.
>>>>>> Unfortunately this breaks taxonomy support of filters.
>>>>>>
>>>>>> Let me first briefly describe how new permissions were supposed to
>>>>>> work.
>>>>>> Role has many filters. Filters has and belongs to many permissions.
>>>>>> Permissions are
>>>>>> grouped by resource. Some resources supports granularity that enable
>>>>>> you
>>>>>> to
>>>>>> define limited filter using scope search syntax. During authorization
>>>>>> you
>>>>>> ask for all objects of a particular resource for which user has a
>>>>>> particular permission. If there's any unlimited filter, you have this
>>>>>> permission for all objects of this resource, otherwise all limited
>>>>>> filters are found, we create a
>>>>>> scoped_search condition by combining these filters with 'OR' and
>>>>>> apply
>>>>>> it
>>>>>> using
>>>>>> search_for on this resource.
>>>>>>
>>>>>> Currently we allow filters to be also related just to some
>>>>>> taxonomies,
>>>>>> so
>>>>>> only
>>>>>> filters for current taxonomies would be applied. E.g. if you are in
>>>>>> Israel
>>>>>> location and ask for hosts you can view, only filters from Israel
>>>>>> location
>>>>>> would be found and applied.
>>>>>>
>>>>>> When we support collections of objects from more taxonomies we can't
>>>>>> apply
>>>>>> similar rule. Since we could end up in situation we found two filters
>>>>>> each
>>>>>> for different organization and combine them with OR. For example it
>>>>>> could
>>>>>> allow user to edit hosts from organization that he or she shouldn't
>>>>>> be
>>>>>> able to edit.
>>>>>> More information at [2]
>>>>>
>>>>> When filtering by both location and organization, the filter should use
>>>>> AND,
>>>>> not OR. This is how it works for the default_scope
>>>>> "with_taxonomy_scope"
>>>>> for hostgroup, domain, subnet, smart proxy, etc.
>>>>>
>>>>> In your situation, let's say a user can edit hosts in "Israel"
>>>>> location,
>>>>> but
>>>>> cannot edit hosts for "Payroll" organization. If the current
>>>>> location/organization is Israel/Payroll, then the user will NOT be able
>>>>> to
>>>>> edit hosts, since they need permission in both Israel AND Payroll.
>>>>>
>>>>> I think taxonomies need to be treated specially with "AND" whereas all
>>>>> other
>>>>> filters use 'OR'.
>>>>
>>>> Agreed, I propose this in two paragraphs below. Just one nitpick for
>>>> clarification, if you select 2 or more taxonomies for filter they should
>>>> be
>>>> combined by OR, like this
>>>>
>>>> "original_scoped_search_condition AND (location = 1 OR location = 2) AND
>>>> (organization = 1 or organization = 2)
>>>
>>> Yes, this makes sense.
>>>
>>>>>> So instead of setting taxonomy for filters we should set taxonomies
>>>>>> for
>>>>>> the
>>>>>> resources themselves using scoped_search (the condition string of
>>>>>> filter).
>>>>>> This
>>>>>> implies that we could apply taxonomies only on resources which
>>>>>> includes
>>>>>> Taxonomix and support scoped search. It seems OK to me since there's
>>>>>> not
>>>>>> much sense in granting e.g. viewing and editing of bookmarks only in
>>>>>> one
>>>>>> taxonomy because you see all of them there.
>>>>>>
>>>>>> Therefore filters wouldn't be searched based on current taxonomies
>>>>>> but
>>>>>> all
>>>>>> of them would be applied. More precisely all of those current user
>>>>>> has
>>>>>> assigned through roles and contains particular permission. Taxonomies
>>>>>> would be added to
>>>>>> filters searches like this "original_condition AND (organization = 1
>>>>>> AND
>>>>>> location = 2). Two or more filters are still combined by (F1) OR
>>>>>> (F2).
>>>>>> This
>>>>>> also implies that a filter that would have taxonomy set would become
>>>>>> limited automatically. Also assigning users to specific taxonomies no
>>>>>> longer make sense
>>>>>> because you define objects they can work with by assigning them roles
>>>>>> and
>>>>>> filters. I think taxonomies should be considered something like tags
>>>>>> and
>>>>>> permissions should define which objects should I see by specifying
>>>>>> these
>>>>>> tags,
>>>>>> otherwise it seems as a second authorization system to me.
>>>>>>
>>>>>> One drawback is that by scoped_search we can't easily say "for all
>>>>>> current
>>>>>> user's organizations". One solution could be to dynamically modify
>>>>>> conditions for user by scoped search ext_method, but since
>>>>>> authorization
>>>>>> is done frequently we should save as much time as possible. Second
>>>>>> solution… well I don't have second solution yet
>>>>>>
>>>>>> So I'd like to have some input especially from Amos and Joseph since
>>>>>> I
>>>>>> think you guys know most about taxonomies. I'd appreciate any input
>>>>>> from
>>>>>> others who are interested. Also I'd like to split the knowledge of
>>>>>> new
>>>>>> permissions model to other devs so we can discuss and find some
>>>>>> solution
>>>>>> in Belgium. …and I don't want be the only one that will solve all
>>>>>> the
>>>>>> permission bugs
>>>>>>
>>>>>> Not to forget, thanks Ivan and Ohad for pointing me to good
>>>>>> directions,
>>>>>> you're
>>>>>> definitely welcome in further discussions.
>>>>>>
>>>>>> [1] by resource I mean objects like Hosts, Subnets, Domains, …
>>>>>> [2] suppose we have location Israel and sublocation Israel/TelAviv,
>>>>>> one
>>>>>> filter
>>>>>> for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv,
>>>>>> now
>>>>>> user enters hosts index with current location set to Israel/TelAviv
>>>>>> and
>>>>>> we display hosts from both locations (because of taxonomy
>>>>>> inheritance),
>>>>>> when we ask for>
>>>>>>
>>>>>> :edit_hosts permission we find and apply both filters (because of the
>>>>>>
>>>>>> same
>>>>>>
>>>>>> reason) which grants :edit_hosts permission also for hosts in Israel
>>>>>> which
>>>>>> was
>>>>>> probably not intended. This is just one of example many cases why and
>>>>>> how
>>>>>> it can fail.
>>>>>
>>>>> The PR (https://github.com/theforeman/foreman/pull/1105) has changed
>>>>> since
>>>>> the deep dive demo. If current location is Israel/TelAviv, then user
>>>>> only
>>>>> sees hosts for Israel/TelAviv. If current location is Israel, then
>>>>> user
>>>>> sees hosts for Israel AND Israel/TelAviv. Only hosts in location
>>>>> Israel/TelAviv can be edited by user. Hosts in location Israel cannot.
>>>>> I
>>>>> think this works. Where is the conflict?
>>>>
>>>> Ok in this case we have different problem. Assume we have two filters
>>>> both
>>>> for
>>>> viewing hosts:
>>>> Filter 1 with search 'domain = example.com' with location set to Israel
>>>> Filter 2 unlimited with location set to Israel/TelAviv
>>>> User selects Israel as current location and goes to hosts index so we ask
>>>> for all hosts that user can view.
>>>>
>>>> We search for all filters (using same rules as for hosts) that grants
>>>>
>>>> :view_host permission and because of inheritance we find both filters.
>>>
>>> No, we now wouldn't find both filters. This is how it was in my demo, but
>>> now it's not. For viewing, you see the current location and it's children
>>> (descendents), not its parents (ancestors). So, in your example, the user
>>> only has permission to see hosts in Israel/TelAviv, not in all Israel, so
>>> the list will be limited to only Israel/TelAviv. Again, it wasn't like
>>> this in my demo which is probably the source of confusion.
>>
>> Ok, sorry you're right. But the same problem exists just in mirror example.
>> You're in Israel and since inheritance now works for descendants, filters
>> from
>> Israel/TelAviv would be found. Therefore you would have unlimited filter from
>> Israel/TelAviv applied on Israel hosts.
>
> What do you mean by unlimited filter? If I understand correctly, we need to allow high level filters to override low-level filters.
>
> For example:
> * CEO can see all hosts in Israel.
> * Tel Aviv sysadmin can allow see hosts in Israel/Tel Aviv
> * CEO cannot see hosts in Israel/Tel Aviv ('bad filter')
>
> Now there is a collision when location is Israel. One filter says CEO can see hosts. Another 'bad filter' says CEO cannot see hosts in Tel Aviv.
>
> In this trivial example, I would say that the top-level permission 'wins' and allow the CEO to see hosts in Tel Aviv.
>
> In code, it's not a matter of combining filters with AND or OR but rather overriding/ignoring some of them that are 'lower' priority.
>

There was no intention to support black-list like filters. They all
behave as a white-list which are basically merged at the end with
(union) (implemented by the ORs).

>>
>>>> Now we
>>>> ask, is there any filter that is unlimited? Answer is yes, therefore we
>>>> do
>>>> not
>>>> perform further filtering and display all hosts from Israel and
>>>> Israel/TelAviv.
>>>> User will see hosts assigned to Israel location with domain =
>>>> 'secret.org'.
>>>
>>> If you use the logic you mentioned above "original_scoped_search_condition
>>> AND (location = 1 OR location = 2)" then it would be 'domain = example.com'
>>> AND location = 'Israel/TelAviv' This would not show hosts with domain =
>>> 'secret.org'
>>
>> Yes with proposed change - taxonomies would be part of scoped search - no
>> more
>> issues with mixing unlimited filters. This also means that a given filter
>> applies just to objects assigned to those taxonomies.
>
>
> Yes, taxonomies are currently part of scoped search. All objects that can be assigned to a taxonomy have a default scope called 'with_taxonomy_scope'
>

Just to clarify. We were talking about adding taxonomy conditions to
filter's scoped-search-string before they are combined with OR.

(filter1's scoped-search-string AND org.id in [1,2] AND loc.id IN [2])
OR (filter2's scoped-search-string AND org.id in [3]) OR …

Note: hypothetical filter2 is omitting location condition because it
does not filter by location.

>
>>>
>>>> What I proposed is not to use same taxonomy logic for filters. I think
>>>> instead
>>>> of filters relations to taxonomies we should add these to scoped_search
>>>> conditions. Therefore every filter with defined taxonomy would be
>>>> limited.
>>>
>>> Yes, this makes sense.
>>>
>>>> One difference with this solution is that we can't say "all hosts within
>>>> all users locations" in scoped search, which was supposed to work by not
>>>> setting any taxonomy to filter before taxonomy inheritance. However there
>>>> should be a solution using ext_method for scoped search.
>>>
>>> I think this will still work to have "all hosts within all users locations"
>>> as long as it satisfies the current organization and other all others
>>> filters. With inheritance, it would now be "all user locations and
>>> descendants of locations" (not ancestors).
>>>
>>> Another area of confusion is that hosts are different than all other
>>> objects, since only hosts have one location and one organization explicitly
>>> assigned. The other objects (domain, hostgroup, etc) have a many-to-many
>>> relationship with locations/organizations.
>>>
>>> I agree that there can be collisions of filters. In these cases, I would
>>> take the 'pessimistic' view and not allow.
>>
>> If I understand correctly, the problem would be when e.g. domain is assigned
>> to two orgs at the same time and there are two filters that would grant some
>> permission like edit where 'name ~ foo*' and second 'name ~ bar', each set
>> for
>> one organization.
>
> Are you allowing name ~ foo* no matter which is the current organization or name ~foo* only within the current organization.
> It's a big difference - AND or OR
> Or maybe you are offering both options?

Let user be assigned to Org1 and Org2.

1. When user has ANY context user will see all hosts matching 'name ~
   foo*' filter and belonging to Org1 and Org2 (including theirs children).

2. When user has context Org1 user will see all hosts matching 'name ~
   foo*' filter and belonging to Org1 (including its children).

Basically current selected taxonomy shows user only a subset of what he
is allowed to see by permissions. When any context is selected user sees
everything what he is allowed to see.

Did I clarify it at least a little bit?

Petr

···

On 29.01.14 11:20, Joseph Magen wrote: > ----- Original Message ----- >> On Monday 27 of January 2014 05:42:19 Joseph Magen wrote: >>> ----- Original Message ----- >>>> On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: >>>>> ----- Original Message -----

In this case both filters would be found and joined by ‘OR’ which is correct
I
think. It allows you to modify domains from particular org which satisfy name
condition and it should not matter which org you have currently selected. Or
would it be to confusing for users?

–
Marek

–
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/groups/opt_out.

[Joseph_Magen]

> From: "Petr Chalupa" <pchalupa@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, January 29, 2014 4:09:02 PM
> Subject: Re: [foreman-dev] New permissions vs taxonomies
>
>
>
> > My comments below.
> >
> >> From: "Marek Hulan" <mhulan@redhat.com>
> >> To: foreman-dev@googlegroups.com
> >> Sent: Wednesday, January 29, 2014 11:55:15 AM
> >> Subject: Re: [foreman-dev] New permissions vs taxonomies
> >>
> >> Comments in text below
> >>
> >>> My reply below
> >>>
> >>>
> >>>> From: "Marek Hulan" <mhulan@redhat.com>
> >>>> To: foreman-dev@googlegroups.com
> >>>> Sent: Monday, January 27, 2014 10:55:03 AM
> >>>> Subject: Re: [foreman-dev] New permissions vs taxonomies
> >>>>
> >>>> Thank you for reply Joseph. please see my answers below
> >>>>
> >>>>>
> >>>>>> From: "Marek Hulan" <mhulan@redhat.com>
> >>>>>> To: foreman-dev@googlegroups.com
> >>>>>> Sent: Thursday, January 23, 2014 4:53:12 PM
> >>>>>> Subject: [foreman-dev] New permissions vs taxonomies
> >>>>>>
> >>>>>> Hello
> >>>>>>
> >>>>>> new permissions get closer and closer to be merged, however there are
> >>>>>> some
> >>>>>> other open PRs that change the way taxonomies work. It seems
> >>>>>> inevitable
> >>>>>> to
> >>>>>> support displaying resources [1] from multiple taxonomies at the same
> >>>>>> time.
> >>>>>> Unfortunately this breaks taxonomy support of filters.
> >>>>>>
> >>>>>> Let me first briefly describe how new permissions were supposed to
> >>>>>> work.
> >>>>>> Role has many filters. Filters has and belongs to many permissions.
> >>>>>> Permissions are
> >>>>>> grouped by resource. Some resources supports granularity that enable
> >>>>>> you
> >>>>>> to
> >>>>>> define limited filter using scope search syntax. During authorization
> >>>>>> you
> >>>>>> ask for all objects of a particular resource for which user has a
> >>>>>> particular permission. If there's any unlimited filter, you have this
> >>>>>> permission for all objects of this resource, otherwise all limited
> >>>>>> filters are found, we create a
> >>>>>> scoped_search condition by combining these filters with 'OR' and
> >>>>>> apply
> >>>>>> it
> >>>>>> using
> >>>>>> search_for on this resource.
> >>>>>>
> >>>>>> Currently we allow filters to be also related just to some
> >>>>>> taxonomies,
> >>>>>> so
> >>>>>> only
> >>>>>> filters for current taxonomies would be applied. E.g. if you are in
> >>>>>> Israel
> >>>>>> location and ask for hosts you can view, only filters from Israel
> >>>>>> location
> >>>>>> would be found and applied.
> >>>>>>
> >>>>>> When we support collections of objects from more taxonomies we can't
> >>>>>> apply
> >>>>>> similar rule. Since we could end up in situation we found two filters
> >>>>>> each
> >>>>>> for different organization and combine them with OR. For example it
> >>>>>> could
> >>>>>> allow user to edit hosts from organization that he or she shouldn't
> >>>>>> be
> >>>>>> able to edit.
> >>>>>> More information at [2]
> >>>>>
> >>>>> When filtering by both location and organization, the filter should use
> >>>>> AND,
> >>>>> not OR. This is how it works for the default_scope
> >>>>> "with_taxonomy_scope"
> >>>>> for hostgroup, domain, subnet, smart proxy, etc.
> >>>>>
> >>>>> In your situation, let's say a user can edit hosts in "Israel"
> >>>>> location,
> >>>>> but
> >>>>> cannot edit hosts for "Payroll" organization. If the current
> >>>>> location/organization is Israel/Payroll, then the user will NOT be able
> >>>>> to
> >>>>> edit hosts, since they need permission in both Israel AND Payroll.
> >>>>>
> >>>>> I think taxonomies need to be treated specially with "AND" whereas all
> >>>>> other
> >>>>> filters use 'OR'.
> >>>>
> >>>> Agreed, I propose this in two paragraphs below. Just one nitpick for
> >>>> clarification, if you select 2 or more taxonomies for filter they should
> >>>> be
> >>>> combined by OR, like this
> >>>>
> >>>> "original_scoped_search_condition AND (location = 1 OR location = 2) AND
> >>>> (organization = 1 or organization = 2)
> >>>
> >>> Yes, this makes sense.
> >>>
> >>>>>> So instead of setting taxonomy for filters we should set taxonomies
> >>>>>> for
> >>>>>> the
> >>>>>> resources themselves using scoped_search (the condition string of
> >>>>>> filter).
> >>>>>> This
> >>>>>> implies that we could apply taxonomies only on resources which
> >>>>>> includes
> >>>>>> Taxonomix and support scoped search. It seems OK to me since there's
> >>>>>> not
> >>>>>> much sense in granting e.g. viewing and editing of bookmarks only in
> >>>>>> one
> >>>>>> taxonomy because you see all of them there.
> >>>>>>
> >>>>>> Therefore filters wouldn't be searched based on current taxonomies
> >>>>>> but
> >>>>>> all
> >>>>>> of them would be applied. More precisely all of those current user
> >>>>>> has
> >>>>>> assigned through roles and contains particular permission. Taxonomies
> >>>>>> would be added to
> >>>>>> filters searches like this "original_condition AND (organization = 1
> >>>>>> AND
> >>>>>> location = 2). Two or more filters are still combined by (F1) OR
> >>>>>> (F2).
> >>>>>> This
> >>>>>> also implies that a filter that would have taxonomy set would become
> >>>>>> limited automatically. Also assigning users to specific taxonomies no
> >>>>>> longer make sense
> >>>>>> because you define objects they can work with by assigning them roles
> >>>>>> and
> >>>>>> filters. I think taxonomies should be considered something like tags
> >>>>>> and
> >>>>>> permissions should define which objects should I see by specifying
> >>>>>> these
> >>>>>> tags,
> >>>>>> otherwise it seems as a second authorization system to me.
> >>>>>>
> >>>>>> One drawback is that by scoped_search we can't easily say "for all
> >>>>>> current
> >>>>>> user's organizations". One solution could be to dynamically modify
> >>>>>> conditions for user by scoped search ext_method, but since
> >>>>>> authorization
> >>>>>> is done frequently we should save as much time as possible. Second
> >>>>>> solution… well I don't have second solution yet
> >>>>>>
> >>>>>> So I'd like to have some input especially from Amos and Joseph since
> >>>>>> I
> >>>>>> think you guys know most about taxonomies. I'd appreciate any input
> >>>>>> from
> >>>>>> others who are interested. Also I'd like to split the knowledge of
> >>>>>> new
> >>>>>> permissions model to other devs so we can discuss and find some
> >>>>>> solution
> >>>>>> in Belgium. …and I don't want be the only one that will solve all
> >>>>>> the
> >>>>>> permission bugs
> >>>>>>
> >>>>>> Not to forget, thanks Ivan and Ohad for pointing me to good
> >>>>>> directions,
> >>>>>> you're
> >>>>>> definitely welcome in further discussions.
> >>>>>>
> >>>>>> [1] by resource I mean objects like Hosts, Subnets, Domains, …
> >>>>>> [2] suppose we have location Israel and sublocation Israel/TelAviv,
> >>>>>> one
> >>>>>> filter
> >>>>>> for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv,
> >>>>>> now
> >>>>>> user enters hosts index with current location set to Israel/TelAviv
> >>>>>> and
> >>>>>> we display hosts from both locations (because of taxonomy
> >>>>>> inheritance),
> >>>>>> when we ask for>
> >>>>>>
> >>>>>> :edit_hosts permission we find and apply both filters (because of the
> >>>>>>
> >>>>>> same
> >>>>>>
> >>>>>> reason) which grants :edit_hosts permission also for hosts in Israel
> >>>>>> which
> >>>>>> was
> >>>>>> probably not intended. This is just one of example many cases why and
> >>>>>> how
> >>>>>> it can fail.
> >>>>>
> >>>>> The PR (https://github.com/theforeman/foreman/pull/1105) has changed
> >>>>> since
> >>>>> the deep dive demo. If current location is Israel/TelAviv, then user
> >>>>> only
> >>>>> sees hosts for Israel/TelAviv. If current location is Israel, then
> >>>>> user
> >>>>> sees hosts for Israel AND Israel/TelAviv. Only hosts in location
> >>>>> Israel/TelAviv can be edited by user. Hosts in location Israel cannot.
> >>>>> I
> >>>>> think this works. Where is the conflict?
> >>>>
> >>>> Ok in this case we have different problem. Assume we have two filters
> >>>> both
> >>>> for
> >>>> viewing hosts:
> >>>> Filter 1 with search 'domain = example.com' with location set to Israel
> >>>> Filter 2 unlimited with location set to Israel/TelAviv
> >>>> User selects Israel as current location and goes to hosts index so we
> >>>> ask
> >>>> for all hosts that user can view.
> >>>>
> >>>> We search for all filters (using same rules as for hosts) that grants
> >>>>
> >>>> :view_host permission and because of inheritance we find both filters.
> >>>
> >>> No, we now wouldn't find both filters. This is how it was in my demo,
> >>> but
> >>> now it's not. For viewing, you see the current location and it's children
> >>> (descendents), not its parents (ancestors). So, in your example, the user
> >>> only has permission to see hosts in Israel/TelAviv, not in all Israel, so
> >>> the list will be limited to only Israel/TelAviv. Again, it wasn't like
> >>> this in my demo which is probably the source of confusion.
> >>
> >> Ok, sorry you're right. But the same problem exists just in mirror
> >> example.
> >> You're in Israel and since inheritance now works for descendants, filters
> >> from
> >> Israel/TelAviv would be found. Therefore you would have unlimited filter
> >> from
> >> Israel/TelAviv applied on Israel hosts.
> >
> > What do you mean by unlimited filter? If I understand correctly, we need
> > to allow high level filters to override low-level filters.
> >
> > For example:
> > * CEO can see all hosts in Israel.
> > * Tel Aviv sysadmin can allow see hosts in Israel/Tel Aviv
> > * CEO cannot see hosts in Israel/Tel Aviv ('bad filter')
> >
> > Now there is a collision when location is Israel. One filter says CEO can
> > see hosts. Another 'bad filter' says CEO cannot see hosts in Tel Aviv.
> >
> > In this trivial example, I would say that the top-level permission 'wins'
> > and allow the CEO to see hosts in Tel Aviv.
> >
> > In code, it's not a matter of combining filters with AND or OR but rather
> > overriding/ignoring some of them that are 'lower' priority.
> >
>
> There was no intention to support black-list like filters. They all
> behave as a white-list which are basically merged at the end with
> (union) (implemented by the ORs).

I wasn't referring to black-list like filters, only about filters that may conflict.

>
> >>
> >>>> Now we
> >>>> ask, is there any filter that is unlimited? Answer is yes, therefore we
> >>>> do
> >>>> not
> >>>> perform further filtering and display all hosts from Israel and
> >>>> Israel/TelAviv.
> >>>> User will see hosts assigned to Israel location with domain =
> >>>> 'secret.org'.
> >>>
> >>> If you use the logic you mentioned above
> >>> "original_scoped_search_condition
> >>> AND (location = 1 OR location = 2)" then it would be 'domain =
> >>> example.com'
> >>> AND location = 'Israel/TelAviv' This would not show hosts with domain =
> >>> 'secret.org'
> >>
> >> Yes with proposed change - taxonomies would be part of scoped search - no
> >> more
> >> issues with mixing unlimited filters. This also means that a given filter
> >> applies just to objects assigned to those taxonomies.
> >
> >
> > Yes, taxonomies are currently part of scoped search. All objects that can
> > be assigned to a taxonomy have a default scope called
> > 'with_taxonomy_scope'
> >
>
> Just to clarify. We were talking about adding taxonomy conditions to
> filter's scoped-search-string before they are combined with OR.
>
> (filter1's scoped-search-string AND org.id in [1,2] AND loc.id IN [2])
> OR (filter2's scoped-search-string AND org.id in [3]) OR …
>
> Note: hypothetical filter2 is omitting location condition because it
> does not filter by location.
>
> >
> >>>
> >>>> What I proposed is not to use same taxonomy logic for filters. I think
> >>>> instead
> >>>> of filters relations to taxonomies we should add these to scoped_search
> >>>> conditions. Therefore every filter with defined taxonomy would be
> >>>> limited.
> >>>
> >>> Yes, this makes sense.
> >>>
> >>>> One difference with this solution is that we can't say "all hosts within
> >>>> all users locations" in scoped search, which was supposed to work by not
> >>>> setting any taxonomy to filter before taxonomy inheritance. However
> >>>> there
> >>>> should be a solution using ext_method for scoped search.
> >>>
> >>> I think this will still work to have "all hosts within all users
> >>> locations"
> >>> as long as it satisfies the current organization and other all others
> >>> filters. With inheritance, it would now be "all user locations and
> >>> descendants of locations" (not ancestors).
> >>>
> >>> Another area of confusion is that hosts are different than all other
> >>> objects, since only hosts have one location and one organization
> >>> explicitly
> >>> assigned. The other objects (domain, hostgroup, etc) have a many-to-many
> >>> relationship with locations/organizations.
> >>>
> >>> I agree that there can be collisions of filters. In these cases, I would
> >>> take the 'pessimistic' view and not allow.
> >>
> >> If I understand correctly, the problem would be when e.g. domain is
> >> assigned
> >> to two orgs at the same time and there are two filters that would grant
> >> some
> >> permission like edit where 'name ~ foo*' and second 'name ~ bar', each set
> >> for
> >> one organization.
> >
> > Are you allowing name ~ foo* no matter which is the current organization or
> > name ~foo* only within the current organization.
> > It's a big difference - AND or OR
> > Or maybe you are offering both options?
>
> Let user be assigned to Org1 and Org2.
>
> 1. When user has ANY context user will see all hosts matching 'name ~
> foo*' filter and belonging to Org1 and Org2 (including theirs children).
>
> 2. When user has context Org1 user will see all hosts matching 'name ~
> foo*' filter and belonging to Org1 (including its children).
>
> Basically current selected taxonomy shows user only a subset of what he
> is allowed to see by permissions. When any context is selected user sees
> everything what he is allowed to see.
>
> Did I clarify it at least a little bit?

Yes. Thanks.

···

----- Original Message ----- > On 29.01.14 11:20, Joseph Magen wrote: > > ----- Original Message ----- > >> On Monday 27 of January 2014 05:42:19 Joseph Magen wrote: > >>> ----- Original Message ----- > >>>> On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: > >>>>> ----- Original Message -----

Petr

In this case both filters would be found and joined by ‘OR’ which is
correct
I
think. It allows you to modify domains from particular org which satisfy
name
condition and it should not matter which org you have currently selected.
Or
would it be to confusing for users?

–
Marek

–
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/groups/opt_out.

–
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/groups/opt_out.

[Petr_Chalupa]

>
>
>> From: "Petr Chalupa" <pchalupa@redhat.com>
>> To: foreman-dev@googlegroups.com
>> Sent: Wednesday, January 29, 2014 4:09:02 PM
>> Subject: Re: [foreman-dev] New permissions vs taxonomies
>>
>>
>>
>>> My comments below.
>>>
>>>> From: "Marek Hulan" <mhulan@redhat.com>
>>>> To: foreman-dev@googlegroups.com
>>>> Sent: Wednesday, January 29, 2014 11:55:15 AM
>>>> Subject: Re: [foreman-dev] New permissions vs taxonomies
>>>>
>>>> Comments in text below
>>>>
>>>>> My reply below
>>>>>
>>>>>
>>>>>> From: "Marek Hulan" <mhulan@redhat.com>
>>>>>> To: foreman-dev@googlegroups.com
>>>>>> Sent: Monday, January 27, 2014 10:55:03 AM
>>>>>> Subject: Re: [foreman-dev] New permissions vs taxonomies
>>>>>>
>>>>>> Thank you for reply Joseph. please see my answers below
>>>>>>
>>>>>>>
>>>>>>>> From: "Marek Hulan" <mhulan@redhat.com>
>>>>>>>> To: foreman-dev@googlegroups.com
>>>>>>>> Sent: Thursday, January 23, 2014 4:53:12 PM
>>>>>>>> Subject: [foreman-dev] New permissions vs taxonomies
>>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> new permissions get closer and closer to be merged, however there are
>>>>>>>> some
>>>>>>>> other open PRs that change the way taxonomies work. It seems
>>>>>>>> inevitable
>>>>>>>> to
>>>>>>>> support displaying resources [1] from multiple taxonomies at the same
>>>>>>>> time.
>>>>>>>> Unfortunately this breaks taxonomy support of filters.
>>>>>>>>
>>>>>>>> Let me first briefly describe how new permissions were supposed to
>>>>>>>> work.
>>>>>>>> Role has many filters. Filters has and belongs to many permissions.
>>>>>>>> Permissions are
>>>>>>>> grouped by resource. Some resources supports granularity that enable
>>>>>>>> you
>>>>>>>> to
>>>>>>>> define limited filter using scope search syntax. During authorization
>>>>>>>> you
>>>>>>>> ask for all objects of a particular resource for which user has a
>>>>>>>> particular permission. If there's any unlimited filter, you have this
>>>>>>>> permission for all objects of this resource, otherwise all limited
>>>>>>>> filters are found, we create a
>>>>>>>> scoped_search condition by combining these filters with 'OR' and
>>>>>>>> apply
>>>>>>>> it
>>>>>>>> using
>>>>>>>> search_for on this resource.
>>>>>>>>
>>>>>>>> Currently we allow filters to be also related just to some
>>>>>>>> taxonomies,
>>>>>>>> so
>>>>>>>> only
>>>>>>>> filters for current taxonomies would be applied. E.g. if you are in
>>>>>>>> Israel
>>>>>>>> location and ask for hosts you can view, only filters from Israel
>>>>>>>> location
>>>>>>>> would be found and applied.
>>>>>>>>
>>>>>>>> When we support collections of objects from more taxonomies we can't
>>>>>>>> apply
>>>>>>>> similar rule. Since we could end up in situation we found two filters
>>>>>>>> each
>>>>>>>> for different organization and combine them with OR. For example it
>>>>>>>> could
>>>>>>>> allow user to edit hosts from organization that he or she shouldn't
>>>>>>>> be
>>>>>>>> able to edit.
>>>>>>>> More information at [2]
>>>>>>>
>>>>>>> When filtering by both location and organization, the filter should use
>>>>>>> AND,
>>>>>>> not OR. This is how it works for the default_scope
>>>>>>> "with_taxonomy_scope"
>>>>>>> for hostgroup, domain, subnet, smart proxy, etc.
>>>>>>>
>>>>>>> In your situation, let's say a user can edit hosts in "Israel"
>>>>>>> location,
>>>>>>> but
>>>>>>> cannot edit hosts for "Payroll" organization. If the current
>>>>>>> location/organization is Israel/Payroll, then the user will NOT be able
>>>>>>> to
>>>>>>> edit hosts, since they need permission in both Israel AND Payroll.
>>>>>>>
>>>>>>> I think taxonomies need to be treated specially with "AND" whereas all
>>>>>>> other
>>>>>>> filters use 'OR'.
>>>>>>
>>>>>> Agreed, I propose this in two paragraphs below. Just one nitpick for
>>>>>> clarification, if you select 2 or more taxonomies for filter they should
>>>>>> be
>>>>>> combined by OR, like this
>>>>>>
>>>>>> "original_scoped_search_condition AND (location = 1 OR location = 2) AND
>>>>>> (organization = 1 or organization = 2)
>>>>>
>>>>> Yes, this makes sense.
>>>>>
>>>>>>>> So instead of setting taxonomy for filters we should set taxonomies
>>>>>>>> for
>>>>>>>> the
>>>>>>>> resources themselves using scoped_search (the condition string of
>>>>>>>> filter).
>>>>>>>> This
>>>>>>>> implies that we could apply taxonomies only on resources which
>>>>>>>> includes
>>>>>>>> Taxonomix and support scoped search. It seems OK to me since there's
>>>>>>>> not
>>>>>>>> much sense in granting e.g. viewing and editing of bookmarks only in
>>>>>>>> one
>>>>>>>> taxonomy because you see all of them there.
>>>>>>>>
>>>>>>>> Therefore filters wouldn't be searched based on current taxonomies
>>>>>>>> but
>>>>>>>> all
>>>>>>>> of them would be applied. More precisely all of those current user
>>>>>>>> has
>>>>>>>> assigned through roles and contains particular permission. Taxonomies
>>>>>>>> would be added to
>>>>>>>> filters searches like this "original_condition AND (organization = 1
>>>>>>>> AND
>>>>>>>> location = 2). Two or more filters are still combined by (F1) OR
>>>>>>>> (F2).
>>>>>>>> This
>>>>>>>> also implies that a filter that would have taxonomy set would become
>>>>>>>> limited automatically. Also assigning users to specific taxonomies no
>>>>>>>> longer make sense
>>>>>>>> because you define objects they can work with by assigning them roles
>>>>>>>> and
>>>>>>>> filters. I think taxonomies should be considered something like tags
>>>>>>>> and
>>>>>>>> permissions should define which objects should I see by specifying
>>>>>>>> these
>>>>>>>> tags,
>>>>>>>> otherwise it seems as a second authorization system to me.
>>>>>>>>
>>>>>>>> One drawback is that by scoped_search we can't easily say "for all
>>>>>>>> current
>>>>>>>> user's organizations". One solution could be to dynamically modify
>>>>>>>> conditions for user by scoped search ext_method, but since
>>>>>>>> authorization
>>>>>>>> is done frequently we should save as much time as possible. Second
>>>>>>>> solution… well I don't have second solution yet
>>>>>>>>
>>>>>>>> So I'd like to have some input especially from Amos and Joseph since
>>>>>>>> I
>>>>>>>> think you guys know most about taxonomies. I'd appreciate any input
>>>>>>>> from
>>>>>>>> others who are interested. Also I'd like to split the knowledge of
>>>>>>>> new
>>>>>>>> permissions model to other devs so we can discuss and find some
>>>>>>>> solution
>>>>>>>> in Belgium. …and I don't want be the only one that will solve all
>>>>>>>> the
>>>>>>>> permission bugs
>>>>>>>>
>>>>>>>> Not to forget, thanks Ivan and Ohad for pointing me to good
>>>>>>>> directions,
>>>>>>>> you're
>>>>>>>> definitely welcome in further discussions.
>>>>>>>>
>>>>>>>> [1] by resource I mean objects like Hosts, Subnets, Domains, …
>>>>>>>> [2] suppose we have location Israel and sublocation Israel/TelAviv,
>>>>>>>> one
>>>>>>>> filter
>>>>>>>> for :view_hosts in Israel, second for :edit_hosts in Israel/TelAviv,
>>>>>>>> now
>>>>>>>> user enters hosts index with current location set to Israel/TelAviv
>>>>>>>> and
>>>>>>>> we display hosts from both locations (because of taxonomy
>>>>>>>> inheritance),
>>>>>>>> when we ask for>
>>>>>>>>
>>>>>>>> :edit_hosts permission we find and apply both filters (because of the
>>>>>>>>
>>>>>>>> same
>>>>>>>>
>>>>>>>> reason) which grants :edit_hosts permission also for hosts in Israel
>>>>>>>> which
>>>>>>>> was
>>>>>>>> probably not intended. This is just one of example many cases why and
>>>>>>>> how
>>>>>>>> it can fail.
>>>>>>>
>>>>>>> The PR (https://github.com/theforeman/foreman/pull/1105) has changed
>>>>>>> since
>>>>>>> the deep dive demo. If current location is Israel/TelAviv, then user
>>>>>>> only
>>>>>>> sees hosts for Israel/TelAviv. If current location is Israel, then
>>>>>>> user
>>>>>>> sees hosts for Israel AND Israel/TelAviv. Only hosts in location
>>>>>>> Israel/TelAviv can be edited by user. Hosts in location Israel cannot.
>>>>>>> I
>>>>>>> think this works. Where is the conflict?
>>>>>>
>>>>>> Ok in this case we have different problem. Assume we have two filters
>>>>>> both
>>>>>> for
>>>>>> viewing hosts:
>>>>>> Filter 1 with search 'domain = example.com' with location set to Israel
>>>>>> Filter 2 unlimited with location set to Israel/TelAviv
>>>>>> User selects Israel as current location and goes to hosts index so we
>>>>>> ask
>>>>>> for all hosts that user can view.
>>>>>>
>>>>>> We search for all filters (using same rules as for hosts) that grants
>>>>>>
>>>>>> :view_host permission and because of inheritance we find both filters.
>>>>>
>>>>> No, we now wouldn't find both filters. This is how it was in my demo,
>>>>> but
>>>>> now it's not. For viewing, you see the current location and it's children
>>>>> (descendents), not its parents (ancestors). So, in your example, the user
>>>>> only has permission to see hosts in Israel/TelAviv, not in all Israel, so
>>>>> the list will be limited to only Israel/TelAviv. Again, it wasn't like
>>>>> this in my demo which is probably the source of confusion.
>>>>
>>>> Ok, sorry you're right. But the same problem exists just in mirror
>>>> example.
>>>> You're in Israel and since inheritance now works for descendants, filters
>>>> from
>>>> Israel/TelAviv would be found. Therefore you would have unlimited filter
>>>> from
>>>> Israel/TelAviv applied on Israel hosts.
>>>
>>> What do you mean by unlimited filter? If I understand correctly, we need
>>> to allow high level filters to override low-level filters.
>>>
>>> For example:
>>> * CEO can see all hosts in Israel.
>>> * Tel Aviv sysadmin can allow see hosts in Israel/Tel Aviv
>>> * CEO cannot see hosts in Israel/Tel Aviv ('bad filter')
>>>
>>> Now there is a collision when location is Israel. One filter says CEO can
>>> see hosts. Another 'bad filter' says CEO cannot see hosts in Tel Aviv.
>>>
>>> In this trivial example, I would say that the top-level permission 'wins'
>>> and allow the CEO to see hosts in Tel Aviv.
>>>
>>> In code, it's not a matter of combining filters with AND or OR but rather
>>> overriding/ignoring some of them that are 'lower' priority.
>>>
>>
>> There was no intention to support black-list like filters. They all
>> behave as a white-list which are basically merged at the end with
>> (union) (implemented by the ORs).
>
> I wasn't referring to black-list like filters, only about filters that may conflict.
>

I've probably missed something, I am not sure how they might conflict.
Filters are only allowing things to see/do. The filter "CEO cannot see
hosts in Israel/Tel Aviv ('bad filter')" cannot be done in current
design. A workaround would have to be used by creating filter associated
with Israel including condition host.location != 'Tel Aviv' for the CEO.

···

On 29.01.14 15:15, Joseph Magen wrote: > ----- Original Message ----- >> On 29.01.14 11:20, Joseph Magen wrote: >>> ----- Original Message ----- >>>> On Monday 27 of January 2014 05:42:19 Joseph Magen wrote: >>>>> ----- Original Message ----- >>>>>> On Monday 27 of January 2014 03:17:05 Joseph Magen wrote: >>>>>>> ----- Original Message -----

Now we
ask, is there any filter that is unlimited? Answer is yes, therefore we
do
not
perform further filtering and display all hosts from Israel and
Israel/TelAviv.
User will see hosts assigned to Israel location with domain =
‘secret.org’.

If you use the logic you mentioned above
"original_scoped_search_condition
AND (location = 1 OR location = 2)" then it would be 'domain =
example.com’
AND location = ‘Israel/TelAviv’ This would not show hosts with domain =
‘secret.org’

Yes with proposed change - taxonomies would be part of scoped search - no
more
issues with mixing unlimited filters. This also means that a given filter
applies just to objects assigned to those taxonomies.

Yes, taxonomies are currently part of scoped search. All objects that can
be assigned to a taxonomy have a default scope called
’with_taxonomy_scope’

Just to clarify. We were talking about adding taxonomy conditions to
filter’s scoped-search-string before they are combined with OR.

(filter1’s scoped-search-string AND org.id in [1,2] AND loc.id IN [2])
OR (filter2’s scoped-search-string AND org.id in [3]) OR …

Note: hypothetical filter2 is omitting location condition because it
does not filter by location.

What I proposed is not to use same taxonomy logic for filters. I think
instead
of filters relations to taxonomies we should add these to scoped_search
conditions. Therefore every filter with defined taxonomy would be
limited.

Yes, this makes sense.

One difference with this solution is that we can’t say “all hosts within
all users locations” in scoped search, which was supposed to work by not
setting any taxonomy to filter before taxonomy inheritance. However
there
should be a solution using ext_method for scoped search.

I think this will still work to have "all hosts within all users
locations"
as long as it satisfies the current organization and other all others
filters. With inheritance, it would now be “all user locations and
descendants of locations” (not ancestors).

Another area of confusion is that hosts are different than all other
objects, since only hosts have one location and one organization
explicitly
assigned. The other objects (domain, hostgroup, etc) have a many-to-many
relationship with locations/organizations.

I agree that there can be collisions of filters. In these cases, I would
take the ‘pessimistic’ view and not allow.

If I understand correctly, the problem would be when e.g. domain is
assigned
to two orgs at the same time and there are two filters that would grant
some
permission like edit where ‘name ~ foo*’ and second ‘name ~ bar’, each set
for
one organization.

Are you allowing name ~ foo* no matter which is the current organization or
name ~foo* only within the current organization.
It’s a big difference - AND or OR
Or maybe you are offering both options?

Let user be assigned to Org1 and Org2.

1. When user has ANY context user will see all hosts matching ‘name ~
   foo*’ filter and belonging to Org1 and Org2 (including theirs children).

2. When user has context Org1 user will see all hosts matching ‘name ~
   foo*’ filter and belonging to Org1 (including its children).

Basically current selected taxonomy shows user only a subset of what he
is allowed to see by permissions. When any context is selected user sees
everything what he is allowed to see.

Did I clarify it at least a little bit?

Yes. Thanks.

Petr

In this case both filters would be found and joined by ‘OR’ which is
correct
I
think. It allows you to modify domains from particular org which satisfy
name
condition and it should not matter which org you have currently selected.
Or
would it be to confusing for users?

–
Marek

–
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/groups/opt_out.

–
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/groups/opt_out.