Reputation:
I'm using the Microsoft Graph API with the .Net SDK.
I'm trying to create a new PlannerTask, and provide a description with it when doing that.
The description for a PlannerTask is on a related object, PlannerTaskDetails, and so that object is "read-only".
This seems to imply that to create a PlannerTask with a Description I have to make at least two calls. The first call creates the PlannerTask, and the second call updates the PlannerTaskDetails.
To update the PlannerTaskDetails, an e-tag is needed. So I used Expand to request that the Details property is populated when returning the created PlannerTask. But it is returned unpopulated (i.e. null).
var task = await graphServiceClient
.Planner
.Tasks
.Request()
.Expand("Details")
.AddAsync(plannerTask);
var taskPlannerDetailsETag = task.Details.GetEtag();
var taskDetails = await graphServiceClient
.Planner
.Tasks[task.Id]
.Details
.Request()
.Header("If-Match", taskPlannerDetailsETag)
.UpdateAsync(new PlannerTaskDetails()
{
Description = officeTask.Body
});
So the next thing to try would be creating the PlannerTask, then making a second call to retrieve the PlannerTaskDetails, and then a third call to update the PlannerTaskDetails. But I think I must be approaching this wrong, 3 network round trips to create a single task with a description seems, well, absurd.
What am I doing wrong?
Upvotes: 1
Views: 1721
Reputation: 1508
Previous reply is outdated. You can set task details fields in the same request as creating the task, and you can also immediately read an item after the create request.
Creating a task, reading the details, then updating the details is currently the correct way of accomplishing this scenario. Note that reading the details immediately after creating the task may fail, as the processing is asynchronous, so you should add some retry logic to have stable behavior. We're working on improvements on this scenario to simplify the process.
Upvotes: 2