Hey guys,
When querying the GET tasks endpoint I always get an empty memberships object even though my tasks are part of a section and a project. Is this a known bug? Here is a screenshot:
Hi @PeshecaLocal,
Huh, that’s very interesting. It does look like a bug. I get the same results.
If you don’t specify any opt_fields parameter, you DO get the Membership info. But if you ask specifically for opt_fields=memberships, you don’t.
@Ross_Grambo, what do you think - it’s a bug, or we’re missing something?
Isn’t it just that you need GET /tasks/9999999999999?opt_fields=memberships.project,memberships.section?
That worked in Asana API Explorer when I added Extra Parameters opt_fields : memberships.project,memberships.section
Larry
1 Like
Yes, I guess that’s correct - you have to ask for the specific sub-objects.
2 Likes
Why is this not a bug? memberships.section and memberships.project both contain gid and resource_type, but it isn’t necessary to call opt_fields=memberships.(project|section).(gid|resource_type)
What happens if another property is added inside memberships? A wildcard would be helpful.
Is there any use-case for the current implementation where an array of null elements is returned? If a task has multiple memberships, the call returns an array with the correct number of null values, but why? This feels like a very inconsistent implementation, isn’t intuitive as a user, and doesn’t seem to add any value/functionality.
Thanks
@Anthony_Tamalonis, I believe it’s done this way for performance reasons; to force requests for fields and limit what’s provided by default. I think this is documented in the developer docs but didn’t try to hunt it down.
Larry
Hmmm. Thanks for the reply, Larry.
Calling projects/1199524911171352/tasks?opt_fields=custom_fields returns all custom fields, including the gid of the currently selected enum (for a dropdown) all with all enum_options for each field with name, color, gid, etc. No need to specify what data within custom fields I want. For a large project that seems like a much larger overhead than memberships.
At the very least opt_fields=memberships and opt_fields=custom_fields are not consistent with each other.
1 Like
Sorry, maybe I didn’t look closely enough. Perhaps @Ross_Grambo can weigh in…
I agree that it’s pretty confusing/unintuitive, but I thinkkk it’s fairly consistent.
From my understanding, the logic is:
Given:
opt_fields=key & key points to some value within Asana
Show the value if the value is one of: String, Number, AsanaObject, or an Array of any of those
An AsanaObject is a first class object. It returns it’s compact form by default. Which is usually gid, resource_type, etc.
Memberships is a one-off object that structures things within it. It is not an “AsanaObject”.
Note: I’m using AsanaObject here but that’s not really what they’re called, so don’t use that term elsewhere
But Why?
You can think of our API as a REST API that acts like GraphQL under the hood. We only show you exactly the fields and information you request. You can be much more efficient by requesting exactly the data you need instead of the entirety of objects.
I wasn’t here when these decisions were made, but it seems like they didn’t want to complicate things for general developers (by forcing them to opt_fields into everything). So they created shortcuts. The most commonly used shortcut, is when you don’t provide any opt_field. We return a predefined set of fields that you’re probably looking for. These predefined sets are manually maintained by our API engineers.
This means there’s commonly more data on the object you’re requesting, but it’s either expensive to fetch or deprecated in some way that we don’t want to expose it by default. If you opt_field directly to it, you’ll still get it.
Looking forward
I’m not on the team making these decisions, but last I knew, the front-runner for improvements to this was to force everyone to use opt_fields.
There’s a lot of benefits from doing this, as we can reach out to specific developers when a field is changing (as we know who’s requesting it), performance improvements, etc. But being on the team I’m on, I’m not looking forward to that day, as the docs will need to be much more thorough to describe how to get your data.
2 Likes
Thanks @Ross_Grambo , that’s a very helpful explanation. If changes are made to enforce opt_fields, this kind of description would be great to have in the documentation. I don’t see any mention of AsanaObjects in the API docs, which might be a bit overkill for most users, but it helps to understand this edge case.
My solution to the problem of not receiving the membership data was to first make a call to get all tasks from a project and then make a call to get all data on each task individually, since I couldn’t figure out how to get the membership data from the first call. Ironically that’s a lot more overhead!
That said, it’s worth considering the resulting behavior of calling opt_fields=memberships. While I understand the logic now, the end result of that call is to always return null data. I’m not saying I’d expect an error, but a guaranteed response of [{},{},{}] isn’t exactly helpful either. It feels like a “gotcha” moment waiting for someone to struggle with.
But seriously, thank you. The Asana API is pretty solid and well-documented, which I appreciate even more now that I’m struggling with some other APIs.
1 Like
I suspect we have a lot of engineers doing this workaround, as we haven’t found a great way to document this -.- For anyone that finds their way to this thread, the best way to do this is an opt_fields in the multiple task request:
/projects/1234567/tasks?opt_fields=name,due_date,memberships.section,memberships.project
1 Like