A Rally subscription administrator observes that a query:
https://rally1.rallydev.com/slm/webservice/v2.0/projectpermission?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/<WORKSPACE_OID>&query=&fetch=true&pagesize=200
returns not only the ProjectPermission objects from workspace but also ProjectPermission objects from other workspaces.
This query, ran by a Rally subscription administrator:
https://rally1.rallydev.com/slm/webservice/v2.0/projectpermission?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/<WORKSPACE_OID>&query=&fetch=true&pagesize=200
will return the same results as the query where workspace query parameter is omitted:
https://rally1.rallydev.com/slm/webservice/v2.0/projectpermission?query=&fetch=true&pagesize=200
The query string allows Project and Workspace parameters to be supplied, but they're ignored.
There is a way for subscription administrator to further filter query results, but this is not a one step process, and there is no direct endpoint that will allow filtering results by project in a single step. However this can be solved programmatically by writing a code that gets the full results and then remove the result that do not belong to a specific workspace. In order to do that both Project and Workspace have to be included in the fetch.
This concept is illustrated by the screenshots from WS API below. A query on ProjectPermission object by username:
returns Project object(as long as we fetch full objects or fetch Project attribute specifically, but there is no Workspace object on ProjectPermission object.
Nevertheless, there is Workspace object on Project object which can be used to further filter results.
Compare JSON of the result of this query:
https://rally1.rallydev.com/slm/webservice/v2.0/projectpermission?query=(User.Name = <USER_NAME>)&fetch=Project&start=1&pagesize=200
Once again, there is no direct endpoint that filter ProjectPermission object by Workspace,but it can be done programmatically with one of the API toolkits in two steps.
There is another nuance about the endpoint that is relevant to this discussion: workspace administrators can hit the endpoint and see permissions only for the workspace(s) where they are an admins.