New additions to the API: team memberships, project default views, and compression

English Forum Developers & API Platform News
1

Hello all! I have a short list of new additions to our API that we’ve accumulated and are ready to share with you.

Team Memberships

We’ve introduced a new resource in the API representing users’ memberships within teams, similar to our existing project membership and workspace membership resources. The membership objects have four fields in them: user, team, is_guest, and the usual resource_type field. All fields are read-only.

You can query for team memberships with the following three routes:

  • GET /team_memberships - requires either a team parameter or a user and workspace parameter
  • GET /users/<user-gid>/team_memberships - requires a workspace parameter
  • GET /teams/<team-gid>/team_memberships - optionally takes a user parameter

And you can get an individual membership by ID with GET /team_memberships/<team-membership-gid>

Project default view

Project objects in the API now have a default_view field on them, which is one of "list", "board", "calendar", or "timeline". This determines the view that users see when they initially open the project in the Asana web app. This field is also writeable, so you’re free to have your apps change the default view as well. Note, though, that changing the default view to a different format will also clear any default sort or filters that were set on the project. (This matches what happens in the web app when a user changes views.)

Gzip compressed responses

We now support Gzip compression in the API, and you can request that responses be compressed by sending an Accept-Encoding: gzip header in your request. If the API returns a compressed response, it will have a corresponding Content-Encoding: gzip header. Many popular HTTP clients will automatically handle decompressing responses, so you might not need to do anything special beyond sending the right header! (For example, Python’s requests package will automatically uncompress gzip responses.)

If you are pulling lots of data from our API, compression can potentially improve performance, as it will take less time to send your app all the packets for the smaller, compressed response.

3 Likes
3

Hmm, I tried this with a .NET HttpWebRequest which is supposed to support compression. I verified that it sent the correct header in the request, but the response didn’t contain the expected header value - from my debug window:

? _request.Headers["Accept-Encoding"]
"gzip"

? result.Headers["Content-Encoding"]
""

@Joe_Trollo, any thoughts?

4

Hi Phil,

I think what you want in this case is actually to set request.AutomaticDecompression = DecompressionMethods.GZip on your request (taken from these docs). I suspect that, because there is a separate canonical way of declaring that you want to use compression, the HttpWebRequest is ignoring any manual Accept-Encoding headers you try to set.

If you want to verify the headers of your request, a good tool to use is httpbin.org. If you make a request to https://httpbin.org/headers the body of the response will contain the request headers, allowing you to more easily verify what headers your app sent.

5

Yes, that’s exactly what I did; sorry, should have shown you my actual code. I was just showing the Accept-Encoding element of the Headers array just before it went out over the wire, but that element got set by my using the AutomaticDecompression statement. FYI I tried both

request.AutomaticDecompression = DecompressionMethods.GZip;
and
request.AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip;

as the latter is what is generally shown in online examples; but in both cases, the Content-Encoding header of the response shows an empty string.

I did try the httpbin.org suggestion and it also showed a blank Content-Encoding header in the response.

Thoughts?


EDIT:

Found the answer here!

When the HttpClientHandler is set to use AutomaticDecompression then the value in content is successfully requested as GZip and then decompressed correctly. But the ContentEncoding value in the response headers collection is empty.

Geez, thanks .NET for doing extra work that we don’t need.

So apparently I have no way of verifying whether this new GZip option is working or not! The only thing I can think of is to run my Flowsana refresh-data operation which does a whole bunch of Asana calls and time it with and without compression. Not sure how good of a test that will be, though, since other factors like rate limiting could interfere with the timing.

1 Like
6

Hello,

How can I find out the team permission for a give project?

  • I can know which team is linked to a given project;
  • I can know if the authed user is part of that team;
  • BUT I can’t know if that team is set as “comment only” :frowning:

asana
asana593×597 40.2 KB

Original post here:

Any help ? This is critical for us. Thanks!

1 Like
7

Hi @denishacquin,

Here’s your answer - it’s not possible, because it wouldn’t be accurate since it can be overridden at the user level:

8

Phil,

I understand how a users membership can be overridden by an explicit project membership. However, without being able to query the permission from the team association with the project there is no way to know what the “implicit” users can do on the project (edit or only comment). That is the value of having the write_access exposed for team->project associations.

So either

  1. having a way to query the team->project write_access
    OR
  2. having an endpoint on the project that allows you to query ALL members (either explicit or implicit via the team)

Would allow better insight into how users are configured in asana.

9

I hear you, @Edward_R - no argument from me!

I don’t work for Asana, though, so all we can do is ask them to have it added to the API.

cc: @Andrew-asana

1 Like