[Bug]: Location API tag_color

[Iizuki]

8.3.6 adds tag_color to a number of API objects. I poked around with Locations a little and discovered some issues. Similar things may be happening with other tag-color enabled objects.

No validation

You can upload nonsense colors from the API. E.g. by creating a new location:

POST /locations

{
  "name": "test loc",
  "tag_color": "the uncolor"
}

UI seems to interpret these as black, while the API continues to return the nonsense value.

Aways null when getting individual locations

GET /locations returns the tag colors as expected but GET /locations/:id has tag_color always null.

Tag color included in references

The API returns a reference object of this shape in many places:

{
  "id": 42,
  "name": "the answer"
}

Now references to locations (e.g. location's parent) look like this:

{
  "id": 42,
  "name": "the answer",
  "tag_color": "#a94949"
}

Was the tag_color added intentionally? It seems like a pretty unimportant piece of knowledge for a reference.

[snipe]

Since colors can be a wide variety of values (hex, rgb, actual text - like red - etc) it’s not really possible to validate.

UI seems to interpret these as black, while the API continues to return the nonsense value.

That's just how browsers handle values they don't understand.

GET /locations returns the tag colors as expected but GET /locations/:id has tag_color always null.

This was fixed in f233408

The API returns a reference object of this shape in many places:

Tag color was added to those API references so that we can display the colors in the table view.