When asana released the new “stories”, they correctly set the old+new values of stories, for existing custom fields at that time.
These were:
number_custom_field_changed
enum_custom_field_changed
text_custom_field_changed
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.
multi_enum_custom_field_changed
people_custom_field_changed
date_custom_field_changed
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
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:
new_multi_enum_values
old_multi_enum_values
new_people_value
old_people_value
new_date_value
old_date_value
2 Likes
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_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
.
3 Likes