Hi Asana developers 
Our team is currently building & fine-tuning a new backup app for Asana. For this we would like to know when a task has received new comments.
Would it be possible to get the total number of comments per task when doing the search tasks, much like the num_subtasks / num_likes / … attributes? And then derive from this whether a task has received new comments?
Any help is much appreciated! Thank you.
FYI - This question is related to this post: Extracting comments in bulk for a project or workspace
1 Like
Sadly, no. There’s no way currently to get the num of stories on a task. Additionally this might lead to weird functionality as stories can collapse in Asana. Collapsing only happens when changes are made quickly, however it could be an issue depending when your sync runs.
I don’t think there’s currently a clean way to do this without using Events or Webhooks.
1 Like
Ok, events and webhooks it is, @Ross_Grambo, do you know if there is way to loop through the events ( Get events on a resource ) but only receive the comments instead (so apply a filter), I don’t see such a parameter in the API docs.
And additionally, from the documentation I understand that through the sync argument in the [GET] events api call, we can’t go back in time. So if I do my very first request on monday 1st January, I’ll have subsequent sync tokens for events after that date, but I’ll never be able to figure out sync tokens that would bring me back in time, right?
only receive the comments instead (so apply a filter), I don’t see such a parameter in the API docs.
I believe this would be done similarly to your other thread with “like” filtering. I’ll wait for the API team to weigh in on why that isn’t working.
And additionally, from the documentation I understand that through the sync argument in the [GET] events api call, we can’t go back in time. So if I do my very first request on monday 1st January, I’ll have subsequent sync tokens for events after that date, but I’ll never be able to figure out sync tokens that would bring me back in time, right?
No, there is no “back in time” for events. Events use the same infrastructure as webhooks. Essentially, when you request /events the first time we give you a sync token that represents that corresponds to a cursor. When you request /events?sync=your_token, we move the cursor forward up to 100 events. If you get <100 events then you’re now up to date. If you receive 100, you’ll probably also get a has_more param, which means there are more events waiting for you to consume (the cursor hasn’t hit the end of the stream it’s on).
Because it’s a cursor, there is no going back once you get the events.
Hi @Ross_Grambo, thanks for the feedback. The [GET] events sync pointer makes sense to me.
Please keep me in the loop on how to get the filtering to work on webhooks and/or the [GET] events endpoint.
Have a nice weekend, and again thanks for all the help so far. Appreciated :)!
1 Like