Enhanced API support for product assignment and product task running
complete
Ramon Schouten
Currently with the API we cannot trigger the actions/tasks when setting a product owership (https://docs.helloid.com/hc/en-us/articles/115003038434-POST-Set-product-ownerships), we would like this to be able to choose to trigger the actions when needed.
On the other hand we always trigger the actions/tasks when deleting a product ownership (https://docs.helloid.com/hc/en-us/articles/115003037214-DELETE-Delete-product-ownership), we would like this to be able to choose to not trigger the actions when needed.
*** Solution: new API end-points for product assignment
M
Michiel van der Veeken
complete
M
Michiel van der Veeken
planned
Planned for 2022.06 release
M
Michiel van der Veeken
Merged in a post:
API: support assigning products to users
E
Eemil
Currently, as an administrator, it's possible to assign products to users. This is done by clicking Self Service -> Administration -> Assign. But the API doesn't have any equivalent functionality.
POST to /api/v1/productownership/ will create an ownership record, but will not trigger any product actions to run.
POST to /api/v1/selfservice/products/request will request the product for a given user, but it must then be approved separately (and there's no approval API.
I propose adding two new body parameters to POST /api/v1/selfservice/products/request, so it behaves like the GUI:
{TriggerEmailActions}: boolean, same behavior as the product assignment GUI
{ImmediatelyApproveProduct}: boolean, same behavior as the product assignment GUI
M
Michiel van der Veeken
under review
E
Eemil
I think this is important to fix, not just because we need the added functionality, but because the API is behaving inconsistently. POST and DELETE should either always trigger actions, or never trigger actions, when given similar arguments.
This current behavior will lead to inconsistent API integrations, if the integrator assumes that the API behaves logically.
M
Michiel van der Veeken
Eemil using the request API you can request a product, but also specify the correct input parameters such as requestedByUserGUID. Depending on the workflow, the request will be approved directly or there is still approval required.
The Self Service administration page is for workflow manual override. This is not supported with the current API calls.
Can you describe your use case?
E
Eemil
Michiel van der Veeken: When creating new products, sometimes the product's owner already has a list of people who should have the product. Rather than assigning the product to these people manually, we would like to automate the process through the API.
Also, we're interested in assigning self-service products using HelloID Provisioning business rules. But this isn't possible, unless the API has the necessary functionality that we can incorporate into a target system. The reason for using products, is that they add a layer of discoverability for end-users (compared to standard AD group memberships through the AD target system).
s
sander slot
Michiel van der Veeken: The problem with requestedbyUserGUID api is that the manager/owner of the product gets a email when its requested with the api. So they dont know what product they need to aprove or is already aproved because of api request.
There was already a ticket for the same question/request.
Hope this finaly can be looked at!
s
sander slot
In this request there is also a bugfix that powershell actions wont run if u give users a product with the API.
So this is important for us that this will be added/fixed