Bug 1514237

Summary:	VPC tags are not honored in Infra provisioning and Service Catalog Item creation
Product:	Red Hat CloudForms Management Engine	Reporter:	ldomb
Component:	Provisioning	Assignee:	Drew Bomhof <dbomhof>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ruslana Babyuk <rbabyuk>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.8.0	CC:	bascar, jhardy, kmorey, lavenel, obarenbo, rbabyuk
Target Milestone:	GA	Keywords:	TestOnly
Target Release:	5.10.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	5.10.0.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1532646 1533139 (view as bug list)		Environment:
Last Closed:	2018-06-21 20:48:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1532646, 1533139

Description ldomb 2017-11-16 21:54:49 UTC

Description of problem:

When a VPC gets tagged with prov scope all and prov scope of the tenan all other vpcs still show up in the drop down. 


Version-Release number of selected component (if applicable):
5.8.1.5.20170725160636_e433fc0

How reproducible:


Steps to Reproduce:
1. Create a new tenant
2. Create a new group which is part of the tenant (tenant admin)
3. Create a new user which is part of that group
4. As a superadmin create tag in cat prov scope wtih the name tenant1
5. Make sure our group has the checkbox check for tenant one under prov scope
5. Go tag any VPC with prov scope all and prov scope tenant1
6. Go tag a template and aws provider with prov scope all and prov scope tenant1
6. Go create a servivce catalog item. You will see all VPC's available. You should only see the one tagged
7. Go through the lifecycle provision dialog. You will see the same behaviour

Actual results:
VPC will show up even if its is not tagged

Expected results:
VPC should only show up if tagged with prov scope all and tenant1

Additional info:

Comment 2 Greg McCullough 2017-11-17 20:12:21 UTC

Drew - This filtering needs to be applied to other cloud objects available to the provisioning dialog as well.  Let's discuss.

Comment 3 CFME Bot 2017-12-20 22:21:48 UTC

https://github.com/ManageIQ/manageiq/pull/16707

Comment 4 CFME Bot 2018-01-08 23:10:54 UTC

New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/14830a7ac7567bbccb1fd13f191f20566e79a3ee

commit 14830a7ac7567bbccb1fd13f191f20566e79a3ee
Author:     Drew Bomhof <dbomhof>
AuthorDate: Wed Dec 20 16:58:01 2017 -0500
Commit:     Drew Bomhof <dbomhof>
CommitDate: Mon Jan 8 16:27:51 2018 -0500

    Added get_targets_for base class methods
    
    1. Turns on RBAC filtering by default at the base class level for all allowed_ methods in the CloudManager class
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1514237

 .../manageiq/providers/cloud_manager/provision_workflow.rb | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

Comment 7 CFME Bot 2018-01-18 01:01:55 UTC

New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/feadd7aa04f052649598c6da073a12c18bce7e31

commit feadd7aa04f052649598c6da073a12c18bce7e31
Author:     Drew Bomhof <dbomhof>
AuthorDate: Tue Jan 16 11:26:00 2018 -0500
Commit:     Drew Bomhof <dbomhof>
CommitDate: Wed Jan 17 10:41:44 2018 -0500

    Add acts_as_miq_taggable to AuthPrivateKey
    
    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

 app/models/auth_private_key.rb                        |  1 +
 .../providers/cloud_manager/provision_workflow.rb     |  2 +-
 .../cloud_manager/provision_workflow_spec.rb          | 19 +++++++++++++++++--
 3 files changed, 19 insertions(+), 3 deletions(-)

Comment 8 Drew Bomhof 2018-02-21 22:38:30 UTC

*** Bug 1534919 has been marked as a duplicate of this bug. ***