You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assigning space roles to users is only possible as long as the user has the organization_user role. Even when the user has other org roles like organization_manager, space roles cannot be assigned. Together with the inconsistent handling of this role in the cf cli this gets confusing to users.
Context
The V2 API assigned the organization_user automatically when assigning any org or space role to a user. V3 does not do so anymore (which is good).
CF CLI inconsistency:
The CF CLI does create the org user role whenever set-space-role is executed. When removing the space roles from the user, the org user role remains and cannot easily be removed by the unset-org-role, but has to be deleted via a cf curl -X DELETE /v3/roles.... In this regards the cf cli is inconsistent. I opened an issue regarding this in the CF CLI repo (cloudfoundry/cli#2496)
Issue with API and suggested improvement:
From an API point of view it would be favourable to be able to assign space roles to a user who already has any org role and not be limited to the org user role. So for example if a user already has the org manager role, it should be possible to give that user space roles.
On deletion of the org user role, currently the CC also checks for space roles. If space roles are assigned to the user, the org user role cannot be removed. In this case it would also be better to check for existing space roles only when the last org role is requested to be removed. So e.g. a user has the org user and org manager role. If the deletion of the org user or org manager role is requested it should succeed, because one org role is still remaining, which gives access to the org and therefore access to the spaces. If, in a second request, the last org role is requested to be deleted it should fail if the user still has space roles in that org assigned.
Possible blockers:
As the V2 API is still in use and hasn't been removed completely, it needs to be checked whether this change could be implemented in a backwards compatible way.
The text was updated successfully, but these errors were encountered:
Issue
Assigning space roles to users is only possible as long as the user has the
organization_user
role. Even when the user has other org roles likeorganization_manager
, space roles cannot be assigned. Together with the inconsistent handling of this role in the cf cli this gets confusing to users.Context
The V2 API assigned the
organization_user
automatically when assigning any org or space role to a user. V3 does not do so anymore (which is good).CF CLI inconsistency:
The CF CLI does create the org user role whenever
set-space-role
is executed. When removing the space roles from the user, the org user role remains and cannot easily be removed by theunset-org-role
, but has to be deleted via acf curl -X DELETE /v3/roles...
. In this regards the cf cli is inconsistent. I opened an issue regarding this in the CF CLI repo (cloudfoundry/cli#2496)Issue with API and suggested improvement:
From an API point of view it would be favourable to be able to assign space roles to a user who already has any org role and not be limited to the org user role. So for example if a user already has the org manager role, it should be possible to give that user space roles.
On deletion of the org user role, currently the CC also checks for space roles. If space roles are assigned to the user, the org user role cannot be removed. In this case it would also be better to check for existing space roles only when the last org role is requested to be removed. So e.g. a user has the org user and org manager role. If the deletion of the org user or org manager role is requested it should succeed, because one org role is still remaining, which gives access to the org and therefore access to the spaces. If, in a second request, the last org role is requested to be deleted it should fail if the user still has space roles in that org assigned.
Possible blockers:
As the V2 API is still in use and hasn't been removed completely, it needs to be checked whether this change could be implemented in a backwards compatible way.
The text was updated successfully, but these errors were encountered: