Our customers reported that our app suddenly doesn’t work correctly.
Our Customer says that everything was normal until today, and our app doesn’t have any changes since a month ago.
We expect the return value of columns api (/rest/api/2/filter/id/columns and /rest/api/2/user/columns) as ‘customfield_xxx’, but actual values is custom field name (ex: ‘Gate 5[Time stamp]’).
According to my dev tools, JSD custom fields are correct, but other custom fields are incorrect.
Hi @dmorrow,
Sorry for interrupting you.
I have no response on Ecosystem Service Desk (DEVHELP-5167) and our customers are in trouble.
Of course we’re searching some fixes on our side, but do you have any solution or workarounds?
Thanks for reaching out to us. The mentioned “unexpected format” is actually our new format that is used for any column item that represents more than one custom field that has the same name and type in the system. Therefore, we cannot use any custom field identifier as the value for such a column item.
We would love to understand a bit more about the use cases of your app on this particular payload to assist you further here. Could you please help us to understand how your app is broken due to the format change?
We’re confused about this behavior change without any announcement. I’m sorry if we missed some notice. Other marketplace partners might be in the same situation.
Currently we do the matching based on the column “value” and the field “key”, which is broken now.
I guess we could find a match in the “clauseNames” list, but what if there is another custom field with the same name: “Test_TextMulti” in the above example?
Thanks for the prompt reply. First of all, we’re sorry that the change is causing your app any inconvenience. It’s likely that there is some gap in our document around the columns APIs that is causing this confusion. The reason why there hasn’t been any announcement is because of that we didn’t consider this as a broken change to the APIs given we’re returning the column item value as mentioned in the document of ColumnItem instead of field id so for a column representing more than one custom field, this is the format we’re using. I think we should have actually handled this change in a better way.
For now, we will pause the rollout of this format change to mitigate the effect and discuss further action in the mentioned DEVHELP ticket. Hope that it sounds good to you.
Thanks for reaching out to us. The mentioned column represents multiple custom fields that have the same name and type. Do you reckon that your app also need to handle multiple custom fields in this case instead of finding one specific custom field?
My suggestion is to match column item value (e.g: Test_TextMulti[Paragraph]) to the clauseNames returned for each field as a workaround and there could be multiple fields matched by the new way. However, the data is closer to the fact about the column item you’re interested in.
In my opinion, this assumption still relies on the implementation details so it’s possibly fragile. It would be very helpful for us if you can help raise some ticket to discuss your use case further with us so we can see if there is a need of any new API to provide a more solid solution.
By the way, we have just paused the rollout of the format change for now. Could you please do me a favor to add your app use case to the DEVHELP-5167 to help us better understand the impact of this change?
It would be very helpful for us if you can help raise some ticket to discuss your use case further with us so we can see if there is a need of any new API to provide a more solid solution.