Creating users via WebAPI--possible to set all project permissions in single API call?

[als68]

Hi,

I have a Python script that I use to automatically add new Rally users. The script uses the Pyral package.

Standard access grants our users Editor permissions to (currently) 184 projects, all children of the MAIN project. I want the script to do 2 things:

a) Dynamically build a list of all projects under the MAIN project (as this list is subject to change by upper management any time).
b) Add the user(s) to all projects.

The problem is, I have to send a single JSON payload for EACH project permission--with there currently being 184 projects under MAIN, executing steps (a) and (b) means performing 368 separate API requests just to add one user. With this number of requests, the many requests fail unless I add a few seconds between requests which makes the process take an extremely long time.

The payload looks something like this:
payloadProjectPermissions = {
'HierarchicalRequirement': {
'Project': techProjectPermissions[i],
'User': newUserID,
'Role': 'Editor'
}
}

Can someone let me know of a way to add ~200 project permissions for a user in a single API call? Or in general, a more efficient way to do this?

[Sagi Gabay]

Hi.

Great question and you're touching on a good issue.

The Web Services API (WSAPI) does have support for batch updates. There is a 'batch' endpoint that can allow a single http post request batching up multiple api requests. Check out the "Bulk Operations" section in the WSAPI page for more information.

We can add up a number of projectpermission updates into such a batch. I've included a text file that has an example for you, it has the URL as well as the JSON example.

However, the "bad" news is that the PyRal kit doesn't support the Batch endpoint and there isn't a pyral object that represents this endpoint. And so, what you can do in your Python code is simply construct this http payload and make a direct http post from your code. But, you will need to make sure you code also checks and handles the http errors.

By the way, I suspect that the reason you added the 'wait' in between your individual calls is for a 'concurrency' error. Is that correct? Did that wait fix it?
From my experience a concurrency error can still occur even with the batch endpoint and so you may need to look into why it's happening.

Normally, we recommend you don't add a 'wait' between your statements but simply retry. So, for example you catch the error, if a concurrency error then resend the same request, perhaps do it twice and almost certainly it'll work - you may want to give that a try instead of a wait (if the issue was the concurrency error).


Let us know if that helped.

Sagi

Attachment(s)

projectpermission_batch_example.txt   855 B 1 version

[als68]

Hi Sagi,

Thank you for the quick reply! That was helpful and I'm glad to hear there are bulk operations. I tried testing out the Batch endpoint (using Postman) using the URL you included in your example. I get a 404 status back with the message "Could not determine Web Services Version from '2.0'".

If I substitute "v2.0" in the URL in place of "2.0" and submit a PUT request, I get back a 405 with the message as "Could not find web service for ?/batch? using request method ?PUT?. However a service does exist at that path using the method(s) ?GET?".

Finally, if I try a GET request at the same URL, I get an error saying "Not able to parse artifact type: batch". Any idea how to get around these errors?

Andy

[Sagi Gabay]

Hi Andy,

The "Batch" endpoint itself only supports http POST method, I apologize for not mentioning it. It's explained under the 'Bulk Operations' section in the WSAPI page:

"The endpoint is located at https://rally1.rallydev.com/slm/webservice/v2.0/batch and supports only POST requests."

Let us know if that helped.

Sagi

[als68]

Hi Sagi,

I was looking at a Bulk Operations document but it wasn't the right one; I've found the correct one on the WSAPI page.

Thank you so much for your prompt help, Sagi! I really appreciate it! I'll give this a try first thing tomorrow.

Andy

[Cathrin Callas]

If all of your users get Editor access to all of the projects, you might consider changing the workspace to set the default access to "Editor". Then your script only needs to create the user and add them to the workspace.  From the workspace editing page: "Note: If default access is given, all users created for the subscription will have access to this workspace and all projects underneath."

[als68]

Hi Cathrin,

Thank you for this info! I didn't realize there was a setting for this. Our current structure is:

WORKSPACE > 1 PROJECT > 3 PROJECTS (one of which is the "main" project, which we grant access to for most users)

What I'll do is, make default Workspace access equal to Editor, then have my script perform a bulk operation (like how Sagi suggested) to _remove_ access to the projects that we don't commonly grant access to, as this is a much smaller list.

I suppose another good option would be move the uncommon projects to a different workspace, but I would need to get upper management's approval for that and I don't think they would go for that.

Thanks a ton for the suggestion, Cathrin!

Andy

[als68]

Hi Cathrin,

If you're still following this thread, I had a follow up: I set the Workspace setting to allow "Editor" permissions to all new users, but the desired effect isn't taking place.

1) I send a POST request to /user/create with UserName and EmailAddress only --> creates the user and with "User" access to the Workspace and "Viewer" access to the top-level project
2) Then I send a PUT request to workspacepermission/create specifying the user OID, workspace OID, and the role of "User" --> existing permissions are not modified.

Can anyone help me make a user inherit the default workplace permissions (which are set to give all new users Editor permission)?