Asana is moving to string IDs [Updated with revised timeline]

English Forum Developers & API
41

Hello all,

Upon assessing the fallout from the most recent “bump” (which properly affected the entire API) we have decided that changing the default behavior across the entire API tomorrow as scheduled would negatively affect far more of our users than we’re comfortable with. As such we are cancelling tomorrow’s activation and are updating our schedule with the following dates:

  • October 15th, 12:00 pm PDT — we will change the default behavior from inactive to active for 24 hours , turning it back to inactive at October 16th, 12:00 pm.
  • October 29th, 12:00 pm PDT — we will change the default behavior from inactive to active and keep it active . From this point on, old behavior will only be accessible by sending an Asana-Disable: string_ids header to temporarily opt-out.

I apologize for this additional churn as we try to balance ease of migration for developers and impact for Asana users.

3 Likes
42

Thanks for the update, good luck :wink:

43

Right? I just read and felt like… ohh man you don’t have anything better to do than making us redo all our stuff?

2 Likes
44

This is actually a pretty minor change in the code, replacing id with gid and update typings :slight_smile: Did you manage to do it?

45

wow, minor… Visual Studio just sticks to 99+ references to ‘id’ and a long and string behave differently, e.g. id = 0 vs id = string.empty or similar.
oh, then there’s the database changes… sad times.
I think this is going to cost upwards of £3k in dev time alone… now to test…

46

Is there an update for the Node client? client.headers doesn’t seems to work here. I can’t find anything about this in the docs nor the wiki from github.

47

Here is a sample that used to work

this.client = Asana.Client.create({
      clientId: environment.asana.clientId,
      redirectUri: environment.asana.redirectUri,
      defaultHeaders: {'Asana-Enable' : 'string_ids'}
    });
1 Like
48

Hello all, I have a short update here: due to an internal issue, we are not enacting this change today. We are monitoring the situation and will reevaluate tomorrow, targeting noon PST again. Sorry for the delay!

49

Hey Joe, is this a correct posting? What change is this referring to?

Signed,
Confused in DC

50

Joe can correct me if I’m wrong, but I believe this is removing the opt out option for string ids. If your app is sending the asana-disable: string_ids header, it will stop working tomorrow. I believe we emailed the apps that are doing this (that we had working emails for).

1 Like
51

@Ross_Grambo is correct. Today we were scheduled to permanently enable the string_ids deprecation, such that apps could no longer opt-out and keep getting numeric IDs. Sending an Asana-Disable: string_ids will no longer have any effect after we make this change, which we will revisit enacting tomorrow.

1 Like
52

We resolved the issue and as of noon PST yesterday, the Asana API no longer supports numeric IDs. It’s been two years since we started planning this deprecation and 18 months since we first published communications about it. Thank you all so much for your patience and understanding throughout this tedious and complicated migration!

2 Likes
53

:champagne: :champagne: :champagne:

3 Likes
55

Hello @Adam_Lambert,

I’m in charge of the PHP Client Library. I created a new post for us to talk about your issue, as I believe it’s more client library related than general string id related. Lets talk on that post.

56

Hi Ross,

  Believe it or not, I got it sorted out between when I posted that

and now. In summary, the switch to GID created two problems for
me:

  1) I had to go locate the project GID's the replaced the old

project ID’s, as the GID’s were not the same numbers. This I did
back in 2019 when the first round of changes broke all my client
side code. But using the GID’s instead of the ID’s didn’t solve
anything - it all still failed for me. So back in 2019 when all
that was going on, I finally gave up and added the header to
ignore the gid thing (forget the exact syntax - but that worked)
and carried on with the code as it had been working at that time.

  2) The change yesterday, of course, broke it all again.  This

time, no headers to fix. So, I grabbed a fresh copy of the PHP
client library, and … still no joy. After beating my head
against the wall for a while, I went and whined in the forum.
Then of course, about 20 mins later, I finally got it working.

  Anyway - to cut to the final point, prior to the GID thing, this

code used to work with the project ID. And replacing the project
ID with the GID did not work.

  $Task = $client->tasks->createInWorkspace(12345678910,

$blahblah); // where 12345678910 was the project ID or the
project GID either one.

But this code does work:

  $Task = $client->tasks->createInWorkspace("12345678910",

$blahblah);

  Because without the quotes, it gets interpreted as an integer

value, which Asana rejects (or at least that’s what I think the
deal is).

  Anyway - not a problem with the library - problem with me not

being a particularly sharp programmer (I’m not actually a
programmer at all, but I ended having to mess around with this
stuff to automate task creation due to the volume of tasks I need
to create on a regular basis).

Thanks,

Adam

57

Oh cool! Happy to hear! You’re more than welcome to reach out if you hit a different issue! :slight_smile:

1 Like