Description of problem: It's not at all clear to a user exactly what tabs/panels he will get access to when given a particular permission. See https://bugzilla.redhat.com/show_bug.cgi?id=796964 In the above bug, there are several issues - 1) that some tabs are enabled, such as GPG keys, for seemingly unrelated permissions (Sync Products). 2) Some permissions are enabled completely outside the user-accessible RBAC settings. Such as, when a user is given a default environment, he automatically gets permissions to register and view systems - even though in the roles UI, he has no permissions. I think 2) should be eliminated entirely. If a customer deliberately gives a user no permission, that's exactly what he should have. Even if he has a default environment, he should not be able to register or view systems. As for 1) I think there should be tooltips or hovertext or something in the RBAC ui panels explaining exactly what each permission grants. Otherwise it's very difficult to use fine-grained permissions, since you can't know exactly what will be granted until you try it. Version-Release number of selected component (if applicable): Katello Version: 0.2.8-1.git.24.b178f46.el6 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I think this warrants a bit of a discussion. #1 is a documentation issue, mostly. At least as things stand now, candlepin permits registration and viewing of systems to all consumers. Katello's default permissions reflect that. #2 is an impedance mismatch between data model and views. You are right that UI should somehow show the relation between roles/permissions and views. I'm not sure hover-over is appropriate for that however, as there could be quite a bit of information there. We probably need an additional panel that shows a list of accessible pages/tabs/fields that UI updates as changes are made to roles/permissions.
This bug was closed because of a lack of activity. If you feel this bug should be reconsidered for attention please feel free to re-open the bug with a comment stating why it should be reconsidered.