We use the /REST/Task/{id} POST operation for creating "child" tasks from other tasks. These tasks show as having been created by the Clarity Administrator user. It would be great if that operation had an additional (optional) parameter to specify an actual user so that this user would get notified once the generated task is done.
Andreas -
How do you get your token for the REST API... If you get it with ClientId/Secret, this is the behavior... But if you get it with a userID/password, then it will use that user's identity for the task.
(I'm not sure if this helps in your situation).
-Matt
Matt - thanks for your response.
So our use case is the following:
We have a couple of preparatory tasks bundled in a sequence that run on the live model and a couple of model-altering and export tasks bundled in another task sequence that does *not* run on the live model. The last task of sequence 1, "RunNextTask" (Dynamo script that does the REST API work using 2-legged authentification), launches sequence 2.
Since sequence 2 is started by the admin user the actual user gets no notification when sequence 2 is done.
I suppose we could build something that uses 3-legged auth where users authenticate once and after that the stored refresh token is used. I guess if we also wanted to specify the task server we would have to in any case as the "launchAndClaim" operation only accepts 3-legged auth.
Or how about an OOTB task to launch other tasks?
We've talked about this a lot over the years. Either a task or a Post Task Action that would run other tasks.
The main thing that holds us back from it is how do we reference the task that you want to launch? The Id? The Name?
And then - if you were to copy the task to another project, what would happen to the reference to the task you want to launch? would it still be launching the task in the old project? or you'd like us to somehow update it?
That's where we always get stuck.
Opinions to help us get un-stuck are welcome!
-Matt
Matt, good to hear that you've already had this on your radar.
As to your questions:
- Post task action vs. task: I think a post task action would make total sense.
- Referencing the task: Since tasks can subsequently be renamed I would favour using the task ID. For an optimal UX it would be nice to have that input as a dropdown that lists all the tasks in the project by name (but internally saving the ID of the task).
- Copying it to another project: Perhaps use the same logic that is already in place for the Target input. It shows model names from the source project but the task doesn't do anything until a new target model from the current project is selected. When copying tasks from another project, I have no reasonable expectation for them to run flawlessly without having first reviewed and modified the task's settings.
