-
Notifications
You must be signed in to change notification settings - Fork 897
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
Added ActAsTaggable concern to MiqRequest model #17466
Added ActAsTaggable concern to MiqRequest model #17466
Conversation
…tAsTaggable concern. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
@yrudman unrecognized command 'ad-label', ignoring... Accepted commands are: add_label, add_reviewer, assign, close_issue, move_issue, remove_label, rm_label, set_milestone |
Checked commit yrudman@582d4ab with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 thanks @yrudman
@miq-bot add-label bug, core, gaprindashvili/yes, fine/yes |
@miq-bot add-label blocker |
Added ActAsTaggable concern to MiqRequest model (cherry picked from commit 5923577) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1583710
Gaprindashvili backport details:
|
Added ActAsTaggable concern to MiqRequest model (cherry picked from commit 5923577) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1583711
Fine backport details:
|
…s-taggable Added ActAsTaggable concern to MiqRequest model (cherry picked from commit 5923577) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1583711
After this fix, I don't have error on requests page, but with a account tied to a subtenant, i'm unable to see any requests even my own. |
@LorkScorguar a subtenant can't see parent tenant requests via the tenant access strategy, only descendant tenant requests. Would you be able to draw a tree/picture of how your tenant structure looks, who created the request (and where they are in the tenant structure), and who's failing to "see" the request (and where they are in the tenant structure). Thanks! |
This is what I have: if a user from sub2Tenant create a request, he can't see other tenant requests (normal) but he can't see request on his tenant (abnormal), even he can't see his own requests. All users get rights from custom roles, not the default ones. I don't know if this can be the problem. |
@LorkScorguar I am not able to recreate this in test. Is it possible the user's role doesn't include the various I wrote the following tests and am able to get your tests to pass with no code changes: diff --git a/spec/lib/rbac/filterer_spec.rb b/spec/lib/rbac/filterer_spec.rb
index 045ff9a204..7c9eba65cc 100644
--- a/spec/lib/rbac/filterer_spec.rb
+++ b/spec/lib/rbac/filterer_spec.rb
@@ -122,6 +122,7 @@ describe Rbac::Filterer do
let(:child_tenant) { FactoryGirl.create(:tenant, :divisible => false, :parent => owner_tenant) }
let(:child_group) { FactoryGirl.create(:miq_group, :tenant => child_tenant) }
+ let(:child_user) { FactoryGirl.create(:user, :miq_groups => [child_group]) }
let(:child_openstack_vm) { FactoryGirl.create(:vm_openstack, :tenant => child_tenant, :miq_group => child_group) }
describe ".search" do
@@ -621,6 +622,35 @@ describe Rbac::Filterer do
end
end
+ context "with accessible_tenant_ids filtering (strategy = :descendants_id)" do
+ it "can see own request" do
+ request = FactoryGirl.create(:miq_host_provision_request, :tenant => owner_tenant, :requester => owner_user)
+ results = described_class.search(:class => "MiqRequest", :user => owner_user).first
+ expect(results).to match_array [request]
+ end
+
+ it "can see other's request in same tenant" do
+ group = FactoryGirl.create(:miq_group, :tenant => owner_tenant)
+ user = FactoryGirl.create(:user, :miq_groups => [group])
+
+ request = FactoryGirl.create(:miq_host_provision_request, :tenant => owner_tenant, :requester => owner_user)
+ results = described_class.search(:class => "MiqRequest", :user => user).first
+ expect(results).to match_array [request]
+ end
+
+ it "can't see parent tenant's request" do
+ FactoryGirl.create(:miq_host_provision_request, :tenant => owner_tenant, :requester => owner_user)
+ results = described_class.search(:class => "MiqRequest", :miq_group => child_group).first
+ expect(results).to match_array []
+ end
+
+ it "can see descendant tenant's request" do
+ request = FactoryGirl.create(:miq_host_provision_request, :tenant => child_tenant, :requester => child_user)
+ results = described_class.search(:class => "MiqRequest", :miq_group => owner_group).first
+ expect(results).to match_array [request]
+ end
+ end
+
context "tenant access strategy VMs and Templates" do
let(:owned_template) { FactoryGirl.create(:template_vmware, :tenant => owner_tenant) }
let(:child_tenant) { FactoryGirl.create(:tenant, :divisible => false, :parent => owner_tenant) }
|
@jrafanie I found the problem. It's not related to role, but to my group. On my group I have a filter by tag which is used to restrict view on some object, but miq_requests doesn't have tags, so users are unable to see their requests. |
Interesting @LorkScorguar. Would you be able to share the exact tag filter? I want to write a test for this. Please change the name of the filter if it's something you don't want to share. What do you think about this @yrudman @gtanzillo @lpichler? |
@jrafanie Here are the informations:
2Tags:
We have 3 user groups: groupA have no problem seeing requests I experiment with requests and giving group right to approve/deny + tag_assign on request allow user to see the request, but tag_assign only didn't help. |
@LorkScorguar thank you for reporting this regression. I have recreated it in large part because of the details you provided. I hope to get a PR opened today to address it. The fix will look like this, I just need to add more tests: diff --git a/app/models/miq_request.rb b/app/models/miq_request.rb
index 14e069e993..8608963093 100644
--- a/app/models/miq_request.rb
+++ b/app/models/miq_request.rb
@@ -12,8 +12,6 @@ class MiqRequest < ApplicationRecord
has_many :miq_approvals, :dependent => :destroy
has_many :miq_request_tasks, :dependent => :destroy
- acts_as_miq_taggable
-
alias_attribute :state, :request_state
serialize :options, Hash
diff --git a/lib/rbac/filterer.rb b/lib/rbac/filterer.rb
index b48ebb7e7b..fc68cbc937 100644
--- a/lib/rbac/filterer.rb
+++ b/lib/rbac/filterer.rb
@@ -54,7 +54,7 @@ module Rbac
VmOrTemplate
)
- TAGGABLE_FILTER_CLASSES = CLASSES_THAT_PARTICIPATE_IN_RBAC - %w(EmsFolder) + %w(MiqGroup User Tenant)
+ TAGGABLE_FILTER_CLASSES = CLASSES_THAT_PARTICIPATE_IN_RBAC - %w(EmsFolder MiqRequest) + %w(MiqGroup User Tenant)
NETWORK_MODELS_FOR_BELONGSTO_FILTER = %w(
CloudNetwork |
MiqRequest was changed to allow ownership for self service and limited self-service users in ManageIQ ManageIQ#17208, BZ: 1545395 This caused a problem if you had tag filters assign to a user's group undefined method `find_tags_by_grouping'. This was fixed in ManageIQ ManageIQ#17466, BZ: 1576129, and shipped with: Fine: https://bugzilla.redhat.com/show_bug.cgi?id=1583711 Gaprindindashvili: https://bugzilla.redhat.com/show_bug.cgi?id=1583710 Unfortunately, this second fix to add taggable caused a new bug: users in groups having tag filters could not see their own requests. This commit changes MiqRequest to no longer be taggable, since it's not even taggable in the UI and instead, we add MiqRequest to a list of models that are RBAC'able but not taggable so we don't try to filter MiqRequest based on a user's group tag filters. Credit goes to github user LorkScorguar who reported this issue and provided lots of diagnostics to help us fix this properly. For gaprindashvili and fine: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1596738 For hammer: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
MiqRequest was changed to allow ownership for self service and limited self-service users in ManageIQ ManageIQ#17208, BZ #1545395 This caused a problem if you had tag filters assign to a user's group undefined method `find_tags_by_grouping'. This was fixed in ManageIQ ManageIQ#17466, BZ #1576129, and shipped with: Fine: BZ #1583711 Gaprindindashvili: BZ #1583710 Unfortunately, this second fix to add taggable caused a new bug: users in groups having tag filters could not see their own requests. This commit changes MiqRequest to no longer be taggable, since it's not even taggable in the UI and instead, we add MiqRequest to a list of models that are RBAC'able but not taggable so we don't try to filter MiqRequest based on a user's group tag filters. Credit goes to github user LorkScorguar who reported this issue and provided lots of diagnostics to help us fix this properly. For gaprindashvili and fine: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1596738 For hammer: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
MiqRequest was changed to allow ownership for self service and limited self-service users in ManageIQ ManageIQ#17208, BZ #1545395 This caused a problem if you had tag filters assign to a user's group undefined method `find_tags_by_grouping'. This was fixed in ManageIQ ManageIQ#17466, BZ #1576129, and shipped with: Fine: BZ #1583711 Gaprindindashvili: BZ #1583710 Unfortunately, this second fix to add taggable caused a new bug: users in groups having tag filters could not see their own requests. This commit changes MiqRequest to no longer be taggable, since it's not even taggable in the UI and instead, we add MiqRequest to a list of models that are RBAC'able but not taggable so we don't try to filter MiqRequest based on a user's group tag filters. Credit goes to github user LorkScorguar who reported this issue and provided lots of diagnostics to help us fix this properly. To test this, simply assign managed filters to a user's group, such as /managed/environments/production, create a request for that user and try to see that user's request. They couldn't see it if they received the intermediate fix, ManageIQ#17466, or if they didn't receive that fix, they'd receive the `find_tags_by_grouping` error shown above. For gaprindashvili and fine: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1596738 For hammer: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
MiqRequest was changed to allow ownership for self service and limited self-service users in ManageIQ ManageIQ#17208, BZ #1545395 This caused a problem if you had tag filters assign to a user's group undefined method `find_tags_by_grouping'. This was fixed in ManageIQ ManageIQ#17466, BZ #1576129, and shipped with: Fine: BZ #1583711 Gaprindindashvili: BZ #1583710 Unfortunately, this second fix to add taggable caused a new bug: users in groups having tag filters could not see their own requests. This commit changes MiqRequest to no longer be taggable, since it's not even taggable in the UI and instead, we add MiqRequest to a list of models that are RBAC'able but not taggable so we don't try to filter MiqRequest based on a user's group tag filters. Credit goes to github user LorkScorguar who reported this issue and provided lots of diagnostics to help us fix this properly. To test this, simply assign managed filters to a user's group, such as /managed/environments/production, create a request for that user and try to see that user's request. They couldn't see it if they received the intermediate fix, ManageIQ#17466, or if they didn't receive that fix, they'd receive the `find_tags_by_grouping` error shown above. For gaprindashvili and fine: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1596738 For hammer: Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
Fixed the followup bug reported by @LorkScorguar in #17656 |
MiqRequest
was added to RBAC in #17208 without addingActAsTaggable
. It cause raisingFixes https://bugzilla.redhat.com/show_bug.cgi?id=1576129
BEFORE:
AFTER:
@miq-bot add-label bug, core, gaprindashvili/yes, fine/yes