Not sure if this is a bug or a design flaw.
We use a managed pipeline service to extract Asana data (Fivetran). Authorisation of this pipeline is done via a single user (important later).
One of our analysts is attempting to build a report that makes use of Asana Stories gathered via our data warehouse, populated via the above pipeline.
Within these stories, when an Asana user is mentioned, the mention is actually stored as a hyperlink the the user’s My Tasks list, which itself appears to be a unique Project within Asana.
Obviously having a random hyperlink is not insightful, so we are attempting to translate this link back to a user name. Sounds striaghtforward, however.
Because our pipeline is authorised from a single user, and that user makes the API requests. The only Project records that are extracted and stored in our DW are those that the API user has access to, which does not include the My Tasks list of other users.
I am aware that by directly querying the API and requesting details on a private project may result in accessing the Owner ID, which we could then use to reference/replace the mention, but this is not feasible given the static nature of our architecture i.e. we can’t make new requests, we can only reference what is in the DW.
Not sure if anyone has any suggestions. The above architecture design is super common. To me, ideally the Stories records contain a direct reference to the Asana User ID and not an obfuscated link to their private project.
1 Like
Hi @Sam_Gabell,
Alas I don’t know of any way to solve your situation given that you can’t do additional API calls.
In general, APIs are typically philosophically designed as sets of building blocks which you can assemble via client code to accomplish the end goal, and Asana’s API fits that mold. Unfortunately in your case you’re not really writing client code so the API is not a great fit for this use case.
@Bastien_Siebman @Frederic_Malenfant you guys have any other ideas here?
Thanks for the input @Phil_Seeman.
I do agree that structurally APIs are not ideal conduits for mass data extraction but until platforms like Asana realise that the need to own and control our own data is not only a fundamental user need but also a moral imperative, we will have to use the tools at our disposal.
To be clear, our architecture design does also support and deliver a significant level of custom functionality built on top of Asana activating a more traditional API use-case but these designs were never intended to interact, nor is there a strong value proposition to enable them to.
For me, and I realise I am but one user, the inherent flaw here feels like the nonsensical methodology for referencing a user within Stories.
Surely it makes more sense to utilise the users identifier as the underlying key for a mention, and not some abstracted reference to their personal project?
I’m fairly sure the reason it works the way it does is that a hyperlink has to go to somewhere in the UI. If they used the user’s gid it wouldn’t be a valid link; there’s nowhere it could go to. So they had to use a UI element that best represented a user.