I noticed an inconsistency in how the addition of new task is notified on webhook, based on how the task is created… so this is bordering to be a bug.
In my webhook I want to be notified when tasks are added to a project (on which I installed my webhook handler).
I thought I can get them consistently, meaning that the event is sent only after I finish editing the title of the task.
This is indeed how it works… IF:
- you create the task in the Board view
- you create the task from the top-right “+” button, where you actually get a form and task is created after pressing “Create Task” button
However, if you are creating the task from the List view (there are at least 3 ways I know to trigger this operation, but all lead to same result) the task created notification is sent while I am editing the title (maybe can try to be slow as the webhooks are not sent in real-time).
This is problematic for me, as I want to have the final title and do some manipulation on it.
Can this be changed/fixed? I think the behavior to wait until editing is finished is cleaner and would be consistent with Board view.
Did anybody notice the same? Or is it something on my side? Is there a setup or something for the task created notification NOT to be sent until the editing of the name is finished?
I haven’t noticed any specific behavioral differences between list and board view but then again I haven’t looked specifically at that.
I have, though, seen that if I’m slow at entering a task name, I can get a webhook event with a partial name before I’m done typing.
But I don’t see that there’s a real solution to this from the Asana side. You say
I think the behavior to wait until editing is finished
but other than the one specific case you mention of a popup form that’s completed with a button, how would Asana know “when editing is finished”? Really all they could do is put in a longer delay before sending the webhook; maybe wait a few seconds longer? That still wouldn’t be perfect, though - you might still get some partial names.
1 Like
I notice a difference between editing the task name in board view (which works as I’d like it to work) and list view (which gives me webhook event with partial name).
As for how to know when editing s finished, that’s easy: when the task name editor loses input focus (i.e. we move to next line, next field). As a developer myself, I see no difficulty in finding out when editing is finished. But perhaps there are other reasons why it’s done this way?
I’d disagree with this approach for two reasons (although they are related to each other):
- It would make the API inconsistent with the web application behavior, which I’d argue is a bad thing.
- What happens if the user types a task name and then without changing focus, goes to lunch or leaves work for the day? Your integration might not find about the task for many hours. What if, without changing focus, the user closes their browser? You’d never know about that task. (Going back to my point #1, the Asana web application avoids these issues by saving almost immediately.)
1 Like
Not that I want to argue, but you are ignoring my first premise, the reason I logged this issue: inconsistency inside Asana itself.
As I mentioned, when you create the task from Board View, it works exactly as I described and it violates your 2 points mentioned above.
When you create the task from Board view, you can start editing your task and go to lunch or close your browser and nothing gets created.
In conclusion, for my webhook this behavior would be easier to manage, but I’m fine to settle for first behavior (which you describe and is the behavior of list view) - as long as it is consistent…
1 Like
Fair point! I hadn’t noticed that inconsistency within the Asana web app but you’re right, it’s there.
It’s a core web app issue then; the API is simply reacting when a change hits their data store and sending it out in a webhook in response. The issue is that the web app UI stores the change in the data store inconsistently between list and board views.
I would suggest you post a new thread in the Product Feedback section of the forum to report this. (Or could could post in the Report a Bug section, but it’s probably not literally a bug since it’s probably “working as designed” - the issue is with the design!)
1 Like
You’re absolutely right here, the issue is not with the API indeed. I’ll create a new post.
2 Likes