I am creating project templates and need a way to link the tasks cloned from the template back to their original task they were cloned from in the template. The primary reason for this is that I will periodically need to reset fields in cloned tasks back to their original template values so I want to use the template as reference.
My plan to do this was to programmatically store on the cloned task the task GID from its respective original task in the template. However, it appears that tasks in templates do not have GIDs of their own, or at least not accessible.
There needs to be a way to access the details of the tasks, including GIDs of tasks, from templates using the getprojecttemplate end point.
I’ve moved your post to the English Forum > Developers & API forum section as that’s the place that the Asana API team monitors.
Unfortunately I pushed/begged/demanded/pleaded for Project Templates 2.0 to have the same features as PT 1.0 had way back when PT 2.0 came out, as it was a regression and we lost a bunch of functionality in PT 2.0 that we had in PT 1.0. But alas I was not successful, and PT 2.0 remains to this day with just a portion of the CRUD functionality that they should have and that we used to have - including the ability to programmatically get the tasks in a project template. If I were you, I would not hold my breath for this functionality.
@John_Baldo here’s a request along the lines of what we’ve discussed before…
@Michael_Barry if you really need to, you could probably create a workaround something like this (fair warning: these notes are off the top of my head):
Set a webhook on the project template (more about this below).
When you need to restore data in a project that came from that template, you’ll reference the task in this “faux template” project.
The purpose of the webhook is that when a change is made to the actual template, you need to re-instantiate the “faux template” from the real one. The webhook will tell you when a change is made to the template so you can re-instantiate it to a new “faux template” project.
Problem: you can’t store the GID of the task in the “faux template” in the same task in the actual project, because every time you have to re-instantiate the “faux template”, the GIDs will be different. So instead, create an ID custom field in the project template; those IDs will propagate to both the “faux template” and real projects that come from that template, so you should be able to use those IDs to map a task in a “faux template” to a task in an actual project when you need to reset a field.
That’s unfortunate to hear that they lost this functionality. It seems so basic/fundamental to have unique IDs on core objects like tasks, particularly tasks that serve as references for other tasks. If anything, they should have gone in the other direction where the ID of the template version of task was automatically injected into the database record of all cloned tasks so there is a permanent linkage. Furthermore, it would be great to push auto updates to all cloned projects/tasks from the template version, similar I suppose to what bundles do.
It does make sense and is a potentially good option if I had no other option. In my case, since I only need to know the template task default start/end days before/after the project due date, my plan is to store these values in their own fields in the task template that can be referenced in the cloned task. My use case is that the project due date may need to shift, in which case I need all incomplete tasks to shift accordingly in line with their original offset day settings. While this approach doesn’t take into account changes in the default settings on the template task post-project launch, I don’t expect those changes in the template to be frequent/material enough to warrant a more complex set-up to read the template.
On the ID field suggestion that is an interesting idea but what I found on the ID field is that those will launch a unique value on a task every time a project is launched from a template. So the same task in both real projects and faux projects would still not have the same value for the ID custom field type. Along these same lines though, there are ways to generate universal GUIDs (several websites can generate lists of them) that could then be entered manually into a text field on the template. When the real projects launch from the template, the tasks will carry these GUIDs that could then be used to reference the corresponding task in a faux-project.
