Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #30394 - allow non-admins deal with untaxed filters #8422

Merged
merged 2 commits into from Jun 18, 2021

Conversation

ezr-ondrej
Copy link
Member

Prior this non-admin user would have to have assigned Role without
taxonomies (global role) to be able to manipulate filters.
This allows manipulating Filters to any User with Filter perms.

Filters with taxonomies mean they apply to taxonomy. But given they have
taxonomies relations, they are expected to be taxable in our permission
model. All taxable resources have to have the same taxonomies as Filter
have.

Some filters doesn't have taxonomies as their underlying resource
doesn't have taxonomies. That mean they were unable to be touched by
non-admins prior this patch.

This also renames the taxable checks to express beter what they mean.

@theforeman-bot
Copy link
Member

Issues: #30394

@ezr-ondrej
Copy link
Member Author

Alternative approach would be checking the role's taxonomies for Filter manipulation, but I believe this is what we want.


if organizations.empty? && locations.empty?
if organizations.blank? && locations.blank?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is wrong

app/services/authorizer.rb Outdated Show resolved Hide resolved
app/models/filter.rb Outdated Show resolved Hide resolved
Copy link
Member

@ares ares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, please split the actual fix from the refactoring to two commits, otherwise makes sense. Left one nit re empty? vs blank?. Also the logging seems to be debuggig leftover :-)


if organizations.empty? && locations.empty?
if organizations.blank? && locations.blank?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this ever be nil? even '' is empty

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. build_taxonomy_search_string guarantees to return a string.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rolled this back, these are not org and loc, but organizations and locations.

find_collection(subject.class, :permission => permission).
where(:id => subject.id).any?
col = find_collection(subject.class, :permission => permission)
Foreman::Logging.logger('permissions').debug col.collect(&:id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps use a block for the message so col.collect(&:id) would only be evaluated if the logger is allowed and debug level set (performance nit)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just removed that.

@ezr-ondrej
Copy link
Member Author

I've split this into two commits to have the rename method separate.

Comment on lines 173 to 182
orgs = if resource_taxable_by_organization?
build_taxonomy_search_string('organization')
else
''
end
locs = if resource_taxable_by_location?
build_taxonomy_search_string('location')
else
''
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I see it here, should build_taxonomy_search_string instead return '' if it's not taxable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks much cleaner now :)

@ezr-ondrej ezr-ondrej force-pushed the filters_not_taxable branch 3 times, most recently from 60def6a to 5df1bcd Compare April 15, 2021 13:44
@ezr-ondrej
Copy link
Member Author

I've fixed tests, so I believe it is ready :)

tbrisker
tbrisker previously approved these changes Jun 1, 2021
Copy link
Member

@tbrisker tbrisker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, looks like all concerns have been addressed. any other comments @ares @ekohl ?

Copy link
Member

@ares ares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just about to test this. Code looks good now, thanks for splitting to two commits, please keep that when merging. I haven't tested, let me know if you need hand with that. Otherwise feel free to merge.

@ekohl
Copy link
Member

ekohl commented Jun 1, 2021

No objections from my side.

@tbrisker
Copy link
Member

tbrisker commented Jun 2, 2021

@ares if you have the reproducer ready for testing that would be helpful :)

@ares
Copy link
Member

ares commented Jun 3, 2021

This seems to cause problems when there is already a filter with Filter permissions that's scoped to the org/loc. From now on, it's invalid and I don't have a way to fix that from UI, because I no longer see the org/loc tabs for this filter. We may need a migration for this.

Otherwise works as expected.

@ezr-ondrej
Copy link
Member Author

Thanks @ares! Great catch! If you could verify the migration fixes the issue for you, it would be great :)

@ezr-ondrej ezr-ondrej requested a review from ares June 9, 2021 09:55
Prior this non-admin user would have to have assigned Role without
taxonomies (global role) to be able to manipulate filters.
This allows manipulating Filters to any User with Filter perms.

Filters with taxonomies mean they apply to taxonomy. But given they have
taxonomies relations, they are expected to be taxable in our permission
model. All taxable resources have to have the same taxonomies as Filter
have.

Some filters doesn't have taxonomies as their underlying resource
doesn't have taxonomies. That mean they were unable to be touched by
non-admins prior this patch.

This also drops current taxonomy relations in migration and force flip
the `Override` flag to false for Filter resource filters.
This renames the taxable check methods on Filter to better express
what they mean. We want to know it the resource is taxable, not if it
has search on taxonomy.
Copy link
Member

@tbrisker tbrisker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, any other comments @ares ?

Copy link
Member

@ares ares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, the migration passes. Merging!

@ares ares merged commit 4476429 into theforeman:develop Jun 18, 2021
@ezr-ondrej ezr-ondrej deleted the filters_not_taxable branch June 22, 2021 08:48
@ezr-ondrej ezr-ondrej added the Needs cherrypick This should be cherrypicked to the stable branches or branches label Jun 23, 2021
@tbrisker
Copy link
Member

Cherry pick in GH-8616

@tbrisker tbrisker removed the Needs cherrypick This should be cherrypicked to the stable branches or branches label Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants