0

In reading the Microsoft Graph documentation, we come across two related resource types:

  1. plannerTask
  2. plannerTaskDetails

Both plannerTask and plannerTaskDetails have an id attribute, which in both cases is 28 characters long and case-sensitive, with validation taken care of Microsoft.

In working with Microsoft Graph, I have noticed that for a given task, plannerTask.id === plannerTaskDetails.id. This makes sense, as there would be no need to define a new id for the details resource type, since this is a one-one relationship and MS may simply re-use the plannerTask id.

However in the documentation, the id's seem to refer to different things. I quote:

  • For plannerTask: "ID of the task"
  • For plannerTaskDetails: "ID of the task details"

This seems to leave the possibility of plannerTask.id !== plannerTaskDetails.id.

I was simply wondering if, in people's experience, if it is safe to assume what I noticed above, i.e. that the two id's are always the same, as it is unclear from working with MS Graph and reading the documentation. Perhaps someone working on MS Planner itself could elucidate.

thesofakillers
  • 290
  • 3
  • 13

2 Answers2

2

You should not make this assumption. From the API perspective, they are different keys. Using Graph API, you don't really need to use the Task details id anywhere, and you can always refer to it as task abc's details.

The id values currently are coincidentally the same, but we are actively investigating some features which would require them to be different. If you take dependency on this, your app will break.

Tarkan Sevilmis
  • 1,443
  • 7
  • 9
0

Yes, but if you are doing a patch call then the If-Match header which is Etag is going to be different. Because although task and task details have the same id they are different objects.

Ashok Subedi
  • 217
  • 2
  • 10
  • Yes, I realized the Etag will be different. Thank you for your answer. Do you happen to be able to tell me how you know that the answer is yes? Is this just from working with it a lot i.e. experience? – thesofakillers Oct 14 '19 at 19:38
  • It came from experience. I built multiple application which automates various planner task and task details in a teams platform. Assuming that they are equal never had any consequences for me. I know the risk that they could be different in the future so I have a backup plan for that too. The way I am saving ids in a table, I have a column for taskId and taskdetailsId. Therefore, even if ids are changed I am always saving both. For now and for a long time I believe, assuming they are equal would be ok. – Ashok Subedi Oct 15 '19 at 00:11