Created attachment 560197 [details]
no provider

Created attachment 560199 [details]
resource cluster exists

So it sounds like the provider does exist but the user has no permission to see it.

This sounds like a requirements question then. Should we limit realm/cluster mapping to users that have both "global realm/cluster" permissions _and_ individual permissions on the providers being mapped, or should realm/cluster permissions be sufficient to map to all providers and the lack of provider permissions only keeps the cluster/realm admin from drilling down into provider details but not from mapping to the providers (only seeing the top-level notion of its name and realms).?

Thought about this for a while, and I believe the answer is that a realm/cluster admin should also need to have permission on any provider he wants to map. Otherwise a realm/cluster admin could conceivably map any provider and use it.

Make sense?

Yes, this makes sense. I'll modify the permissions to require permission on both ends (realm permissions for the front end realm/cluster, and provider 'USE' permission on the back-end provider.

One more bit of clarification here. As it turns out, there is no role that imparts 'USE' permission on a provider currently. In fact the only roles we have on providers are 'Provider Administrator' on an individual provider and 'Global Provider Administrator' that adds provider admin for all providers.

Is it OK to require 'Provider Admin' on a provider to map realms to that provider (in which case all I need to do is make sure that the admin roles include the 'USE' rights)? Or do we need to add a 'Provider User' role (both Global and resource-specific) that allows 'VIEW' and 'USE' rights on the provider (and perhaps 'Create Provider Account') so that a Realm Administrator could have permissions to map to all (or some) providers without necessarily being able to add/modify/view providers or provider account credentials.

I'm thinking what I'll do here is add a 'Provider User' role that allows using (but not modifying) a particular provider and also allows creation of new provider accounts on the provider (but no edit/access rights to provider accounts created by others).

In addition I'll add a 'Global Provider User' role that allows using (but not modifying) all providers, but in this case it does not allow provider account creation (since allowing global account creation is something more relevant to a global provider administrator).

Agree this is a blocker, moving to beta 5 though.

Patch posted: https://fedorahosted.org/pipermail/aeolus-devel/2012-March/009461.html

Note this depends on the fix for 800511

Pushed to master at: 030d1b6bd01d3823198d4494dce945ef8fd05ca9

assigning to Pushpesh

1. A user is not able visit the "Cloud Resource Provider" tab even if the user is having "Provider User" access on at least one Provider account.(Bug,taking Scott comments as requirement )

2. A user is not able visit the "Cloud Resource Provider" tab even if the user is having "Global Provider User" access.(Bug,taking Scott comments as requirement )

3. A local Provider Administrator is able to update the accounts already added by admin.(Expected Behaviour)

4. A local Provider Administrator is able to add only those accounts to cloud(using local cloud administrator access) for which are associated with its Provider (Expected Behaviour)

5. A Global Provider Administrator is able to add all accounts to cloud(using local cloud administrator access) associated with any Provider (Expected Behaviour)

Marking this bug to assigned due to 1-2.Considering this as partial fix.

1. The user doesn't need to visit the provider tab to map clusters -- the "Provider User" role assigned on the provider should suffice. The problem reported here ("provider user can't access provider view") is already reported as a separate bug (bug 808031).

2. This is a manifestation of the same bug as above. It's a requirement for the admin to grant a user the 'provider user' for a Provider or 'global provider user' in order to allow the user to map cloud resource clusters to providers, but the user doesn't have to visit the provider view in order to do the mapping. i.e. the 'access denied' is a valid bug, but it's already covered on 808031 and is prioritized separately there.

Since 808031 already covers 1 and 2, since you verified 3, 4, and 5, I think this means we can close out this bug.

Moving back to ON_QA since I think the failed bits are separate from the main bug here (and are already covered by another BZ)

(In reply to comment #15)
> 1. A user is not able visit the "Cloud Resource Provider" tab even if the user
> is having "Provider User" access on at least one Provider account.(Bug,taking
> Scott comments as requirement )
> 
> 2. A user is not able visit the "Cloud Resource Provider" tab even if the user
> is having "Global Provider User" access.(Bug,taking Scott comments as
> requirement )
> 
> 3. A local Provider Administrator is able to update the accounts already added
> by admin.(Expected Behaviour)
> 
> 4. A local Provider Administrator is able to add only those accounts to
> cloud(using local cloud administrator access) for which are associated with its
> Provider (Expected Behaviour)
> 
> 5. A Global Provider Administrator is able to add all accounts to cloud(using
> local cloud administrator access) associated with any Provider (Expected
> Behaviour)
> 
> Marking this bug to assigned due to 1-2.Considering this as partial fix.

Agree 3,4,5 are fixed... 1 and 2 are covered by 808031

marking this bug as verified..

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0583.html