Roles inheritance for groups is not visible in user's role assignments

[Dmitri]

If I applied role inheritance to a group GR-A in scope of project PR-A:

(PUT) /v3/OS-INHERIT/projects/PR-A/groups/GR-A/roles/ROLE-A/inherited_to_projects

this role assignment is listed in the result of:

(GET) /v3/role_assignments?scope.project.id=PR-A&group.id=GR-A

but is not in the result of:

(GET) /v3/role_assignments?scope.project.id=PR-A&user.id=USR-A&effective

whereby USR-A is a member of the group GR-A.

BUT it is part of result of the query:

(GET) /v3/role_assignments?scope.project.id=SUB-PR-A&user.id=USR-A&effective

whereby SUB-PR-A is a child of PR-A.

I think the inherited roles assignment should be valid in the project scope of PR-A for both groups and users.

[Henry Nash (henry-nash)]

This bug is invalid, since:

1) Inheritance is only applied to children of the node that carries the actual inherited assignment
2) Effective assignments only show the result of all group & inherited assignments, as well as valid non-inedited direct user assignments - but do not include the source assignments that generate these results

The "inherit only on children" comes from the heritage of inheritance, which was originally designed to only be placed on domains, and all the projects in the domain would get the assignment. We considered changing this for project-project inheritance, but decided it would be too confusing to have two types of inheritance rules.

If in the above example, you also want there user to have a role on PR-A, then you need to have a second (non-inherited) assignment (either for the user of the group) on PR-A

[Dmitri (dmitri-voronov)]

Thanks a lot for your explanation!
But for me is more confusing the fact that the group has a role assignment but its members don’t.
In my opinion it is also inconsistent with API documentation
http://developer.openstack.org/api-ref-identity-v3-ext.html#identity_v3_OS-INHERIT-ext