After adding the user to followers, the “modified_at” task’s field has been changed (updated to current timestamp), but after removing the user from followers, it did not.
Hello, @Jeff_Schneider . May I know if I have encountered a data consistency problem in the API, or this is normal behavior?
Hi @Roman_Horbach, when I test this, I get the same behavior that you do. I’m not certain if this was the original intent of the eng team that built it or not. I will look into if this is intended behavior or a bug.
An alternative approach would be to use events. If your app needs to know when a user was removed from a task (or other actions), removing a user from a task does generate an event.
The tasks schema for modified_at says: “The time at which this task was last modified. Note: This does not currently reflect any changes in associations such as projects or comments that may have been added or removed from the task.”
This leads me to believe that associations such as adding or removing a follower are not intended to change the modified at time. It may be a bug that the timestamp changes for followers added.
3 Likes
@Jeff_Schneider, thank you for your quick response.
In my case, I need to monitor changes in followers of all tasks in the workspace. Events API are not suitable for this case, because I cannot receive events for the entire workspace, but only for individual tasks or projects. Sometimes for similar tasks I used Audit logs API, but information about changes in task followers is not writes there.
I couldn’t find information about whether it’s possible to listen to events for several thousand projects at the same time. If the Asana allows this use of the API, then I can try to go this way.
Anyway, I will wait for your inspecting of the ‘modified_at’ field in the tasks. Thanks a lot!!
@Roman_Horbach, I spoke with the eng team that is responsible for this aspect of the our product code. The short answer is that adding a follower creates a story, removing a follower does not.
Tracking every follower of a task is an unusual use case (it’s the first time I’ve personally come across it in 7+ years). We have an audit log API that may be able to assist with the underlying business need, but doesn’t track task followers.
Another audit approach is to put webhooks on all projects to monitor all events in real time. There is a limit of 10,000 webhooks per token so if you have more than 10,000 projects, you will need to use more than one Service Account to auth the script. You can also use the events API to poll for events on a cadence. You can use higher-level webhooks (e.g. on a domain), but it won’t provide task level updates.
Here are some other known cases about when modified_at is updated or not updated
Task.modified_at is updated when…
- story is created or trashed on a task
- attachment is trashed on a task
- task is assigned or unassigned
- custom field value is changed
- the task itself is trashed
- the following fields are updated:
- completed
- name
- due_date
- description
- attachments
- items
- schedule_status
- a subtask is added to the task
- a subtask on the task is re-homed (given a new parent task or converted to a parent task)
Task.modified_at is NOT updated when…
- a subtask on the task is completed or deleted
- a follower is remvoed
Project.modified_at is NOT updated when…
- a new custom field is added to the project
Note: this list is likely not exhaustive. I will continue to investigate and update the dev docs with the findings.
4 Likes
Thank you very much for your answer, and thank you for the work you did. Now I understand how tickets change after updating related entities, and I will look for another solution to my problem, instead of monitoring the “modified_at” field.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.