Limit task attachments to what Asana application shows

Community Forum English Developers & API
1

Relevant Asana API Endpoint: Get Attachments for Task

Using the endpoint to get all attachments related to a task includes inline attachments (including those in stories). This is clearly documented behavior:

Note that within the Asana app, inline images in the task description do not appear in the index of image thumbnails nor as stories in the task. However, requests made to GET /attachments for a task will return all of the images in the task, including inline images.

Source: Get attachments from an object

The Problem: Retrieving only “pure” task attachments

As I try replicating the same attachments gallery experience as the Asana webapp, I am consistently wrestling with filtering the task attachments array so that it contains ONLY attachments that are not represented elsewhere.

The problem is that I do not need to request ALL stories of each task. However, this prevents me from properly filtering the attachments array since I cannot parse the html_text of the task stories to know which attachments are actually inline within stories.

I also do not always need to request each task’s html_text. This also prevents me from detecting the inline attachments for filtering.

Question

Does anyone have a performant solution for this? How can we use the Asana API (sparingly and optimally) to replicate the attachments gallery on a task within the Asana webapp?

1 Like
2

Alas, even the parent datapoints of each attachment prove unhelpful. See the Attachments Schema: Attachments

My hope was that the attachment’s parent would denote the actual origination of the attachment, distinguishing whether it came from a story or the task itself. Still, a parent concept wouldn’t distinguish between being an inline attachment of a task vs a pure attachment of a task in this line of thinking.

However, the parent of the attachment was always the task of which I’m already using to fetch the attachments.

A potential and desirable solution to this problem would be if a datapoint was added to the Attachment schema to understand where and how the attachment originates. I very much like the resource_type and resource_subtype concept which made me think of this.

1 Like