Labels_positions_v2 is not always returned by the API

Hi there :wave:t2:
I noticed that the labels_positions_v2 is not always returned by the API for color/status columns in settings_str.
Is it an expected behavior? What is the rule?
For me, something goes wrong, because if you use a default board on a standard account, the api returns:
{
“labels”: {“0”:“Working on it”,“1”:“Done”,“2”:“Stuck”}
}
which is not the correct order: when labels_positions_v2 is set, it is re-ordered this way:
{
“labels”: {“0”:“Working on it”,“1”:“Done”,“2”:“Stuck”},
“labels_positions_v2”: {“0”:0,“1”:2,“2”:1}
}
which is correct.

1 Like

Hey there @jeromeskiply :wave:

Thank you for bringing this to our attention! I appreciate your insight here.

Just to make sure we are on the same page here, in terms of order, are you referring to the way the labels appear in the UI on a blank board by default? That is:

  1. Working on it
  2. Stuck
  3. Done

It seems like by default, the Status labels are ordered based on their color index and that is the way they appear in the settings_str as well:

image

Am I following along correctly? Let me know :slight_smile:

-Alex

Hi @AlexSavchuk, we are on the same page.
For our QR Code App, we used the labels_positions to render the status code in the same order than it is in the interace.
As labels_positions are not always returned, there is a kind of discrepency: when labels_positions is not present, we use the color order, and when it is, we use the interface order. It could be natural to let labels_positions systematically. This confusion caused a bug spotted by @amir in our app (solved) because on our account, labels_positions was always present due to the fact that default status were set.

1 Like

@jeromeskiply

Thank you for circling back with me so quickly, I appreciate it!

Glad we’re in alignment here - I will check back on this with the team and investigate this more closely to see what might be the root cause here. Thanks for flagging this behavior!

-Alex

1 Like