When asana released the new “stories”, they correctly set the old+new values of stories, for existing custom fields at that time.
and we can get old+new values in these fields:
old_text_value, new_text_value, old_number_value, new_number_value, old_enum_value, new_enum_value.
But, for those created after, we never got any values for old + new data in stories.
I tried to guess which names it could be, in opt_field, but I never got any any results.
old/new people value??
old/new multi_enum value??
Where are they?
Hi @Frederic_Malenfant, the reason why you are not able to access these properties is because we have yet to add these properties to our story schema. We will update you once we have added these properties. Also, feel free to follow our API Changelog topic for updates on this and other API changes.
Just wanted to follow up with you and let you know that we have added the following properties to our story schema:
Thank you @John_Vu , I am actually adding these to our application.
I just want to let you know that, I found someting a little bit strange.
The structure used to store the custom field “date”, is the same that you uses for the “due date”, that is, due_on due_at !
A custom field of type “date” is not a due date!
I understand that you keep the same structure as found in the “old/new_dates” property.
Hi @Frederic_Malenfant, glad to hear that you are adding these to your application. As for your encounter with the strange behavior, I am not sure if I follow. Can you explain some more. We don’t have a
date property on our custom field schema but we do have
date_value property. Also, when you refer to
due_at which schema is this part of? or are you just talking about these properties in general?
Hi @John_Vu ,
That’s what I mean, look at that story:
"text": "Frédéric changed cf_date_heure from \"January 16, 12:00pm\" to \"January 16, 3:00pm\"",
That custom fields have nothing to do with a “due_on/at”.
It’s not a “due” date, it’s just a date type custom field.
Thank you for the detailed explanation and example. This makes much more sense now. I agree that this naming doesn’t make sense for all use cases. For example, you can have a custom field of type date called “Birthday” and if someone changes this date a story with the date value inside of
due_at can be confusing.
I have informed our API team about this issue and they told me that we will work on adding a
date_time parameter to this object value for
old_date_value. The reason why we are adding these values as opposed to renaming the existing
due_at is to prevent breaking changes. In the future we will likely deprecate the
due_at from this object value.
I will keep you posted on the status of these new object parameters. For now, if this is blocking you please continue to use the values in