Documentation inconsistent about Roles at org level / project level

The documentation makes two different statements:

A role can only be defined within a project scope

The latter would seem untrue since the initial dev configuration creates roles for admin and anon at both the global and org level, and the documentation here walks you through creating roles at global scope

Another question I have is about inheritance. If I grant the ability to create hosts at an org level, should this flow down to projects? It doesn’t appear to in practice. So roles at the org and global layer only affect the ability to manage items at that layer? e.g. groups, users, orgs, and projects respectively?

Thanks @jorhett - I’m updating the docs to fix this in

I’m going to ping @mgaffney to answer the inheritance question.

Hi @jorhett,
The grants assigned to a role are only applicable within the scope of the role’s “grant scope ID”. They do not apply to any child scopes of the “grant scope ID”.

Can you help explain the use case for the separation of the grant scope id? If granted rights can only apply at a project level, what value is there in separating the role’s location from the grant’s location?

Not intending to challenge. I’m fairly certain you have an idea in mind, I’m just missing it myself and hoping to understand while setting internal standards for u/g/r placement.

A role can be defined at any scope level not just the project level. The grant scope id of a role can only be the scope id of the defining scope or one of the child scopes of the defining scope. Delegating admin tasks is one example were this could be useful. For example, a role with a grant of id=*;type=*;actions=* defined at an org level with a grant scope id of a child project would allow the admin of an organization to delegate administration of a project.