Hi Brad,

I'd like some clarification and priorities before I start looking at what can and cannot be done, because honestly, RBAC support is very vague.

The doc mentions we want RBAC support for repos, playbooks, and credentials.
This does not involve ownership, only exposing them to users as an administrator, and being able to "use" repos, playbooks, and credentials exposed to me by the administrator.

RBAC involves many things:
1) ownership (which is already not included, so yay, this is off.

2) tagging - do you want to be able to tag repos, playbooks, and credentials with "production" or "marketing", etc.?

3) Do we have the concept of RBAC for credentials elsewhere?  Typically, I believe the credentials for a CI/endpoint are only exposed if you have rbac for the CI item.  If so, where do the credentials for this feature "live"?

4) Are there specific places/screens that we currently show ALL the things that we want to ensure RBAC filters out?  If so, which screens?

5) Are there specific "actions" for ansible repos, playbooks, credentials, etc. that we would like to be given to users or groups?  Think start vm, stop vm.  Do we need to add these product features for these actions into the user/role permissions tree?

6) RBAC is often lumped together with tenancy.  Please confirm this RFE does not include tenancy or adhoc tenancy sharing.

7) Are there specific reports/widgets for these things that I need to confirm we filter through RBAC?

Note, Gregg had this note in the doc:

M-5 scope. Need to support tagging on these objects (including UI), enforce RBAC on these objects, also identify places where RBAC should not be enforced such as a user ordering a service that results in running a playbook and using credentials.

This implies we definitely need 2), tagging.
Can you clarify what is meant by service ordering running a playbook using credentials?  Are we suggesting we could have different RBAC results on services that use RBAC filtered playbooks and credentials?  Is the implication that if a service is created with certain RBAC and you're allowed to see that, then you should be able to order the service regardless if you can RBAC the playbook or credentials associated with it?

Summarizing a discussion with Brad:

Ansible playbooks can use credentials for various systems from within the playbook, not our provider credentials.  We are talking about these credentials internal to ansible, not ours.

We already have the ability to edit tags on the tower provider's configured systems, job templates, etc.
We need to ensure we can edit tags on playbooks, repos, credentials.

Embedded ansible providers need to also be able to edit tags on the configured systems, job templates, playbooks, credentials, repos, etc.  We do not have these in the UI currently at all for embedded ansible.

Playbooks need separate rbac from credentials since you might give the same playbook to different sets of users with different credentials.
The admin will be responsible for giving access to credentials needed in a playbook.

Being able to run the specific actions for the playbooks, credentials, repo is priority 1

Our View screens need to be filtered (automation -> ansible tower -> explorer) (same for embedded ansible)
Reporting is a lesser scope but might come for free with view screen filtering.

There are no custom actions, so no new product features to add as of yet.

We'll assume that the tenancy feature for Service/ServiceTemplate/ServiceTemplateCatalog will be sufficient for now.

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

* We already have backend support for tagging and RBAC filtering for ansible playbooks, credentials and repositories

Based on what Brad and I discussed above, the only work to be done for this initial RBAC support for ansible objects is to make these things viewable and taggable in the UI.  The backend already has support for this.

UI inconsistency:

* Embedded ansible: 
 * there is no provider shown in the UI
 * playbooks, repositories, and credentials are shown in the UI (I'm not sure how you even create these without a UI for ansible)
 * There are no configured systems or job templates shown

* Ansible tower provider: 
 * there is a provider shown in the UI
 * configured systems
    You cannot tag from the Configured systems accordion, only by navigating to 
    the configured system from the provider accordion.

 * job templates
  You can tag job templates.
 * there are no playbooks, repositories or credentials shown in the UI

Hi Harpreet, this appears to be ready for UI work.  We have support for tagging and RBAC filtering for these objects already.  I only wrote new tests confirming our backend support for ansible object rbac.  See above comments describing what's wanted.

Hi Harpreet, do the PRs above fix the inconsistency between the ansible tower provider and the embedded ansible provider as described in comment 7?  If so, I'd expect this would have worked in 5.9.2.0 as is since they've been backported since then.

If not, we'll have to check with Brad if that's something we should handle in a followup.  I believe the ansible tower provider looks different from the embedded ansible (the one that we can currently tag and do rbac against in the UI) on purpose.

New commit detected on ManageIQ/manageiq/master:

https://github.com/ManageIQ/manageiq/commit/5acc3ec6daa71ed01f6e111e5fba9bc3e97fce7a
commit 5acc3ec6daa71ed01f6e111e5fba9bc3e97fce7a
Author:     Joe Rafaniello <jrafanie>
AuthorDate: Tue Jun  5 13:39:53 2018 -0400
Commit:     Joe Rafaniello <jrafanie>
CommitDate: Tue Jun  5 13:39:53 2018 -0400

    Add tests for RBAC on ansible playbooks and auth

    https://bugzilla.redhat.com/show_bug.cgi?id=1531629

 spec/lib/rbac/filterer_spec.rb | 37 +
 1 file changed, 37 insertions(+)

Joe, I discussed with Brad and fixing inconsistencies between Tower and embedded ansible are out of scope for this release (and this RFE).