tl;dr: Per a previous post, we are making breaking changes to the way that user task lists (i.e. My Tasks) work in Asana. Developers can now test some of the new behavior by passing Asana-Enable: new_user_task_lists as a request header. If your app interacts with user task lists, please read!
Hi everyone,
I’m Yacob and I’m a Product Engineer here at Asana. In this previous post, I came to tell you all about some important changes coming to My Tasks that impact our APIs. I’m back to let you all know about how you can opt-in to test the deprecation.
As I mentioned in the last post, the changes we’re making to user task lists are happening via a migration so after we start the migration, there will be no way to opt-in or opt-out to change the API behavior . To that end, we wanted to give you a way to test the new API behavior before we start the migration.
Important info for updating your app to test the deprecation:
The name of the deprecation is new_user_task_lists so as per our deprecation documentation, you can opt in to the new behavior by passing the following header in your requests: Asana-Enable: new_user_task_lists
Notably the two things you’ll be able to test with that header are:
If an app calls the PUT /tasks/{task_gid} endpoint with an assignee_status, no changes will be made to the assignee_status property.
If an app calls the GET /tasks/{task_gid} endpoint or any endpoint that returns metadata about a task, we will no longer return the assignee_status property in the response payload, even if it is explicitly requested via opt_fields.
Additionally, as mentioned in the last post, we will be exposing a migration status on user task list resources. The new property is user_task_list.migration_status. It is an string with 2 valid values: not_migrated or completed
For understanding the full plan for this deprecation and our breaking changes, please refer to the original post linked above!
Please let us know if you have any questions about this. We’ll be watching this thread for questions and will update this post as necessary to provide more information or clarification.
Will there be any opportunity to test the other major aspect of the change, true column-sections, perhaps in a sandbox environment or in specific workspaces, prior to the actual start of migration?
Any update on when you think the migration will begin, and/or how long you think it might take?
Looks like you decided on a different name for the migration flag than in the last post; is it still a boolean and will migration_status = true mean migration has occurred?
While I appreciate your update, what a number of us really need is a response to my post from 2.5 months ago to the thread you cited:
It seems there’s no evidence to the contrary that task auto promotion is going away with no concrete plan/timeline to replace it. This will be disruptive to many users and clients and, to some extent, some of our reputations as Certified Pros / Ambassadors.
Hi @lpb and @Bastien_Siebman, thanks for sharing your feedback with us. The updates to My Tasks are still in development, which is why we haven’t shared any recent updates.
When we’re closer to release, we’ll post an announcement letting all customers know about the changes, along with resources for how to best use the improved My Tasks. As members of the Asana Together Community, you will also get access to additional resources to help your team and clients with this change.
Once we have news and resources to share, we will proactively post here in the Forum. Please stay tuned for updates in early 2021.
Will there be any opportunity to test the other major aspect of the change, true column-sections, perhaps in a sandbox environment or in specific workspaces, prior to the actual start of migration?
we’re working to see if this is possible (to allow some folks from the Forum to test this out in specific workspaces). I’ll let you know ASAP as we develop those plans.
Any update on when you think the migration will begin, and/or how long you think it might take?
We’re currently estimating that it will start in roughly late January or early February, but this is subject to change. We will definitely let you all know. Per our current best guess, itshould take ~3-4 months.
Looks like you decided on a different name for the migration flag than in the last post; is it still a boolean and will migration_status = true mean migration has occurred?
Thanks for calling this out! I should clarify in the original post. This is now an string with 2 valid values: not_migrated or completed. I’ll edit the original post to make this clearer
For our purposes in reading this in the API, it won’t literally be an enum custom field (with enum gids and the like), right? For us I assume it will be a string with one of those two possible values in it?
Thanks for the reply! I thought it was deprecated because of the message saying that the function is affected by the change and as a result wouldn’t work unless I accounted for it. I’m glad that it was indeed documented somewhere and that I was just looking in the wrong place!
This change seems to affect the [post] tasks endpoint? While this is not mentioned in this or the previous post.
Currently when calling the post task endpoint, a task is created but a error response is returned “This request is affected by the “new_user_task_lists” deprecation. Please visit this url for more info: Update on our planned API changes to user task lists (a.k.a. My Tasks)
Adding “new_user_task_lists” to your “Asana-Enable” or “Asana-Disable” header will opt in/out to this deprecation and suppress this warning.”
Probably because after a successful post the api redirects to the get endpoint? Curious how to resolve this issue?
That error is logged when one of our client libraries sees an active deprecation that you may be affected by. Your code execution shouldn’t be hindered by this log.
In order to stop it from logging, you should opt_in to the new functionality and make sure your app doesn’t have any new issues. You can do this when you define your client. In node-asana, it looks like:
I couldn’t find the information about the deprecation periods (start, end etc.) can you guide me to this information. The most up to date source I found is your post here but I’m still lacking information.
I seem to remember that API changes are usually done in 3 phases (first opt in, then opt out, then new behaviour only) but I can’t find this in the deprecation documentation anywhere → is this the case for this change?
What is the time plan for the phases and where are we now (when is the default behaviour changed / how long can I use the flags for the old behaviour)?