Implement display options for Boolean types

[kgodey]

Problem

The boolean data type supports the following display options:

• Whether to show the field as a checkbox or a dropdown.
• Whether to show custom labels for TRUE and FALSE
• Custom label names for TRUE and FALSE

Solution

(1) We should store these display options in the following format in the display_options field of the corresponding column.

{
  "input": "dropdown",
  "use_custom_labels": true,
  "custom_labels": {
    "TRUE": "yes",
    "FALSE": "no"
  }
}

(2) We should also validate these so that:

• Only columns of this type can have these display options. They should not be able to be set if the column is of a different type.
• input should be set to either checkbox or dropdown
• use_custom_labels should be a boolean
• custom_labels can only have the keys TRUE and FALSE

(3) If the column type is changed, the display options should be deleted.

(4) We should add supported display options to the types endpoint.

Additional Context

• Design for Boolean type options on Figma
• Blocked by Set up Column Django model with support for display options #658
• Spec for implementing display options for Columns #392

[silentninja]

@kgodey @pavish @seancolsen Do we actually need to use_custom_columns field, shouldn't custom_labels be enough, you either set it or you don't

[pavish]

I don't see a need for the use_custom_labels field.

[kgodey]

According to our API standards, we need to always include all keys in responses:

The portion of the API response describing to a given resource should always contain the same set of keys.

So as long as we don't ever skip the custom_labels key in the response, I'm good.

[silentninja]

Got into a nasty bug with nested serializer partial update. JsonField default update method makes it even worse as partial update ends up replacing the whole object on the database but acts as a partial object on the serializer.

Do we need partial update for display_options , I am thinking of disabling partial update for the custom columns as it makes sense to treat the JSON field as immutable, but this could be supported if needed.

[kgodey]

@silentninja I'm not sure what you mean by partial update for display_options, could you elaborate?

[silentninja]

Should we support updating certain fields of display_options instead of specifying the complete options during a patch request to columns API

For example:
Should this API request be allowed:

PATCH - table/id/columns/id - {'display_options': {'"custom_labels": {
    "TRUE": "yes",
    "FALSE": "no"
  }}

or should the display options be specified only as a whole object(acts like a put request for the display_options field):

PATCH - table/id/columns/id - {'display_options': {'"custom_labels": {
    "TRUE": "yes",
    "FALSE": "no"
  }, 'input': 'dropdown'}

[kgodey]

We should not allow nested partial serialization. display_options should only be specified as a full object. We're following this pattern elsewhere as well.

[silentninja]

(4) We should add supported display options to the types endpoint.

Should the endpoint return just the keys of the supported display_options or the complete list with the values/choices allowed(something like Entity value attribute)?

Entity value attribute would mean something like

{'BOOLEAN': {"options": [{"name": "input",
                       "values": ['dropdown', 'checkbox']
}]}}

Not sure if this would work for options that need nested data. I prefer to have the display option structure in the API documentation.

[kgodey]

I like the entity value attribute option. Our eventual goal is for the frontend to be completely unaware of types (see #661) so I think we'll need that.