Rally User permission management using Rally Rest API via PermissionMap - Update users to Subscription Admins and Workspace Admins

Products

• Rally SaaS

Issue/Introduction

We are looking to automate Rally user creation and permission management using Rally API and able to use API to create a user. 
Permission for users with default projects (as per subscription admin) works, but we want to give permission to users on specific projects (across workspaces and projects).

 

 

Resolution

Below is an overview of how to utilize the PermissionMap. While it is not an officially supported API it can serve your required purpose. However, there is a limitation: You must wait for the update request to complete before initiating the next one. Additionally, please note that the API is accessible only to subscription admin users or API keys associated with subscription admin accounts.

Here is the API call to update a user to a Subscription Admin:

POST https://rally1.rallydev.com/slm/webservice/v2.0/user/<UserObjectID>/setpermissionflags

Body:

{"SetPermissionFlags":{
"SubscriptionAdmin":true
}
}

Here is the API call to update a user to a Workspace Admin: POST https://rally1.rallydev.com/slm/webservice/v2.0/user/<UserObjectID>/permissionmap

Here is the body:

{"NoAccessWorkspaces":[],
 "EditorProjects":[],
 "UserWorkspaces":[],
 "AdminProjects":[],
 "ViewerProjects":[],
 "AdminWorkspaces":[<WorkspaceObjectID>],
 "MembershipProjects":[],
 "NoMembershipProjects":[],
 "NoAccessProjects":[]}

Below is the PermissionMap endpoint information.

PermissionMap
Note	User Permission Map
REST URLs	Operation HTTP Method Encoding URL Read GET    JSON      https://rally1.rallydev.com/slm/webservice/v2.0/user/ObjectID/permissionmap Update POST JSON https://rally1.rallydev.com/slm/webservice/v2.0/user/ObjectID/permissionmap   Usage: The read operation returns a json result of all the workspaces and projects the user potentially could have access to. The oids are already sorted into the different list. To add an oid to a list, the update operation needs to be invoked. The corresponding change needs to be put into the right list. So granting access is done via adding the correct oid to a list that grants access like: EditorProjects, AdminProjects, MembershipProjects, ViewerProjects for Projects, or AdminWorkspaces, UserWorkspaces for Workspaces. To revoke access the correct oid has to be added to the revoking lists like: NoAccessWorkspaces for Workspaces and NoAccessProjects or NoMembershipProjects for Projects.
Version Compatibility	API version 2.0
Child Elements	NoAccessWorkspaces Required True Note List of workspace oids that the user should have no access to Type Array of integer   EditorProjects Required True Note List of project oids that the user should be editor in Type Array of integer   UserWorkspaces Required True Note List of workspace oids that the user should have access to Type Array of integer   AdminProjects Required True Note List of project oids that the user should be project administrator Type Array of integer   ViewerProjects Required True Note List of project oids that the user should be project viewer Type Array of integer   AdminWorkspaces Required True Note List of workspace oids that the user should be workspace administrator Type Array of integer   MembershipProjects Required True Note List of project oids that the user should be project member Type Array of integer   NoMembershipProjects Required True Note List of project oids that the user should NOT be project member Type Array of integer     NoAccessProjects Required True Note List of project oids that the user should NOT have access to Type Array of integer