Currently, if an external app updates a task and as part of that update, includes a value for a custom field which value is already set on that task, the Asana API will perform a write operation on that task anyway; and if there is a rule trigger in place based on that value being set, that rule will fire even though the value didn’t change.
For example, say I have a task with a custom field “Priority” set to a value of “High”. And I have this rule in place:
Now say I send an update to that task via the API whose purpose is to update the task’s name, but in that update I also send the task’s other current properties which include the Priority custom field and its current value of “High”.
The result is that even though the only property I changed in my update is the task’s name, because I sent the custom field value, Asana writes it, which causes the rules engine to think that custom field got set to High (even though it already was set that way), which causes the above rule to fire - I’d argue inappropriately.
What do all of you developers think? Is this behavior OK and the solution is, “If the custom field value didn’t change, then you just shouldn’t send it as part of your update”, or would you consider this a bug/design flaw which Asana should correct?
@Kem_Ozbek
@anon65323026
2 Likes
@Phil_Seeman is this the issue we have talking about, and also mentioned by @Julien_RENAUD recently? Nice catch.
I would find It normal to consider the value was “written” but not “updated” or “changed”. So the rule should not fire imho.
1 Like
Yes, it is - it’s the cause of the issue @Julien_RENAUD brought up recently and also the one you ran into with @Bryan_West a while ago.
Thank you for a detailed writeup of this behavior @Phil_Seeman! I am generally in agreement that the behavior you described (unchanged values are not written to and thus do not cause rules to fire) is desirable here. That said, our documentation for PUT endpoints consistently states:
Only the fields provided in the data block will be updated; any unspecified fields will remain unchanged
This does suggest that fields included in the PUT request will be updated, and updated fields can cause rules to fire. In addition, the current behavior seems consistent with the RFC 7231 spec for handling PUT requests. Based on that, I wouldn’t consider the current behavior a bug, though I’d also hesitate to label it the “ideal design”. To avoid the undesired behavior in the current state, we would recommend that you only include fields in your PUT request that you want to change and be written to, as you pointed out. But again, I acknowledge that the current behavior presents a potential “gotcha” for our developer community and requires more effort on the part of developers to avoid the unwanted firing of rules.
At this point in time, we see the workaround as a readily accessible solution to the problem which lowers the priority of improving this behavior (relative to continuing to push for API feature parity with our web product and new API features!). However, I encourage readers and developers in our community to speak up if this presents a significant challenge when building using the Asana API; seeing this topic generate traction would naturally feed into the way we prioritize making improvements to our API.
2 Likes
Thanks, @anon65323026!
While, as you can tell from my post, I would like for Asana to change this behavior so as not to update unchanged fields, you have a valuable point here. As we know, Asana engineering work is not an unlimited resource, and there is this question of weighing how we would like that resource allocated!
1 Like