| Summary: | Global Provider User not able to use any provider | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | Shveta <ssachdev> | ||||||||
| Component: | aeolus-conductor | Assignee: | Angus Thomas <athomas> | ||||||||
| Status: | CLOSED NOTABUG | QA Contact: | wes hayutin <whayutin> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 1.0.0 | CC: | akarol, deltacloud-maint, hbrock, ssachdev, sseago | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-05-07 17:28:15 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Shveta
2012-04-02 13:10:33 UTC
What did you try to do with this user? I think right now the only place that the 'use' permission on providers is checked is for adding Realm/cluster mappings. If you can do that, this role is working properly. There is currently an issue (already in BZ) that provider user can't access the provider details page. The reason is that, for now, the provider details page is the edit page, which currently requires Modify permissions. Also, I noticed that when you added the 'provider user' -- you did it by removing the 'Global Profile User' permissions. Note that the roles doc already cautions that if you remove 'Global Profile User' your user will no longer be able to launch Applications, since access to the profiles is required. Created attachment 574729 [details]
cluster_1
ok .. i tried using providers in clusters but as shown in attached screenshot , i can't create new cluster with this role neither can i edit an existing cluster
Created attachment 574730 [details]
cluster
Global Provider User doesn't grant access to create realm -- it just includes the proper permissions on the providers. Create/edit cluster permissions are currently only included in "Global Realm Administrator" or the overall Administrator role. The issue here is you need permissions on both ends of the association -- permission to edit realms, and permission to access providers. We haven't included global provider access in the Realm Admin role since it's possible that there may be users who need to create realms but don't have permission to access all providers. Since there's a valid use case for separating the permissions, we've made them separate roles. Some 'Realm Admins' may also have global provider user, but others may have only permission to map selected providers. In the future we'll provide a "role management" UI that will allow administrators to add/remove privileges from the defined roles, which would allow these two to be combined in situations where it makes sense. Scott are we saying this is an RFE? or future bug Wes: Neither -- I'm saying that this is not a bug -- in order to map providers to realms you need the ability to Create/Modify realms _and_ the ability to use the provider you're mapping. The last comment about a future 'role management' UI is just pointing out that at some point in the future, an administrator could combine both roles in one, but for now they're separate since it's not clear that in all cases they should be combined (some customers may want to have a finer-grained control over what providers the Realm admins hace access to). However, I would not construe this bug as "fixed by a role management UI" -- I think it's simply NOTABUG. Things are working as we designed them to work here. Whether (and when) we add a role management UI will be driven by the post-1.0 feature development process, and it really doesn't relate to the subject of this bug directly. Closing per Scott |