missing data in stories for custom fields

When asana released the new “stories”, they correctly set the old+new values of stories, for existing custom fields at that time.

These were:

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_date_value ??
old/new people value??
old/new multi_enum value??

Where are they?

Thank you.

1 Like

Good question, @Frederic_Malenfant!

@AndrewWong @sasha_f ?

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.

1 Like

Hi @Frederic_Malenfant,

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! :slight_smile:

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_date, due_on, and 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:

GET /stories/1203714297143373?opt_fields=text,resource_subtype,old_date_value,new_date_value

	"gid": "1203714297143373",
	"new_date_value": {
		"due_on": "2023-01-17",
		"due_at": "2023-01-16T20:00:00.000Z"
	"old_date_value": {
		"due_on": "2023-01-17",
		"due_at": "2023-01-16T17:00:00.000Z"
	"text": "Frédéric changed cf_date_heure from \"January 16, 12:00pm\" to \"January 16, 3:00pm\"",
	"resource_subtype": "date_custom_field_changed"

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.

1 Like

Hi @Frederic_Malenfant,

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_on and 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 and date_time parameter to this object value for new_date_value and old_date_value. The reason why we are adding these values as opposed to renaming the existing due_on and due_at is to prevent breaking changes. In the future we will likely deprecate the due_on and 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 due_on and due_at.