-
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
Add acts_as_miq_taggable to AuthPrivateKey #16828
Add acts_as_miq_taggable to AuthPrivateKey #16828
Conversation
@miq-bot add_label wip, bug, blocker, providers @miq-bot assign @gmcculloug cc - @gtanzillo |
@gtanzillo - Would you mind taking a look at this PR. The |
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.
@syncrou Looks good!
@gtanzillo If |
I was thinking about that too but didn't see a use case for universally enabling tagging on all authentications. Like provider credentials. That said, I don't think it would hurt anything either. |
@gtanzillo - Thanks GT! @miq-bot remove_label wip |
@@ -74,7 +74,10 @@ | |||
FactoryGirl.create(:classification_cost_center_with_tags) | |||
admin.current_group.entitlement = Entitlement.create!(:filters => {'managed' => [['/managed/cc/001']], | |||
'belongsto' => []}) | |||
|
|||
2.times do | |||
kp = ManageIQ::Providers::CloudManager::AuthKeyPair.create(:name => "auth_1") |
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.
I realize this won't matter but if we are going to name the elements with a number should we give them unique names?
Maybe:
2.times do |i|
kp = ManageIQ::Providers::CloudManager::AuthKeyPair.create(:name => "auth_#{i}")
end
You can even use i + 1
here if you don't want a zero element name. 😄
58cda8c
to
0e7c31e
Compare
The RBAC filtering was not 100% applied to the AuthPrivate key class which caused tagging to fail. This change allows key_pairs to return correctly when run through RBAC when being tagged https://bugzilla.redhat.com/show_bug.cgi?id=1514237
0e7c31e
to
feadd7a
Compare
Checked commit syncrou@feadd7a with ruby 2.3.3, rubocop 0.52.0, haml-lint 0.20.0, and yamllint 1.10.0 |
Add acts_as_miq_taggable to AuthPrivateKey (cherry picked from commit fad3529) https://bugzilla.redhat.com/show_bug.cgi?id=1532646
Gaprindashvili backport details:
|
Add acts_as_miq_taggable to AuthPrivateKey (cherry picked from commit fad3529) https://bugzilla.redhat.com/show_bug.cgi?id=1533139
Fine backport details:
|
The Authentication class is needed in the CLASSES_THAT_PARTICIPATE_IN_RBAC array in order for the AuthPrivateKey class to participate in RBAC. PR where this was introduced: ManageIQ#16828
…o_rbac Add acts_as_miq_taggable to AuthPrivateKey (cherry picked from commit fad3529) https://bugzilla.redhat.com/show_bug.cgi?id=1533139
The Authentication class is needed in the CLASSES_THAT_PARTICIPATE_IN_RBAC array in order for the AuthPrivateKey class to participate in RBAC. PR where this was introduced: ManageIQ#16828
The RBAC filtering was not 100% applied to the AuthPrivate key class which
caused tagging to fail. This change allows
key_pairs
to return correctly whenrun through RBAC when being tagged
https://bugzilla.redhat.com/show_bug.cgi?id=1514237