Summary
The Metabase API supports a number of settable attributes on fields and tables — visibility, display name, search behavior, etc. — but core-spec/v1/spec.md doesn't list them, so the extractor doesn't emit them and the format can't round-trip them. Anyone wanting to manage these from a YAML source of truth has to invent local extensions.
Attributes proposed for inclusion
Field-level
| Attribute |
Type |
Notes |
visibility_type |
enum string |
normal | details-only | sensitive | hidden | retired. Drives whether the field appears in pickers and result tables. |
display_name |
string |
UI override for the column name. Metabase auto-humanizes when unset (e.g. patient_id → Patient ID), so the extractor would want a "skip when auto-default" rule. |
has_field_values |
enum string |
list | search | auto-list | none. Controls dropdown behavior. |
caveats |
string |
Free-form. |
points_of_interest |
string |
Free-form. |
preview_display |
boolean |
Whether to show in row previews. |
json_unfolding |
boolean |
Whether to expand JSON columns into nested fields. |
custom_position |
integer |
UI ordering. |
Table-level
| Attribute |
Type |
Notes |
visibility_type |
enum string |
hidden | technical | cruft. Null means visible. |
display_name |
string |
UI override. |
entity_type |
string |
E.g. entity/UserTable, entity/EventTable. Drives some Metabase-side semantic behavior. |
caveats |
string |
Free-form. |
points_of_interest |
string |
Free-form. |
Why this matters
Without these in the spec, every consumer has to:
- Layer local extensions on top of the format.
- Patch the extractor or post-process its output.
- Document custom round-trip semantics.
Adding them to the spec — and emitting them from extract-table-metadata when set — would let teams manage the full visible metadata surface declaratively without forking the tool.
Open questions
- Should the extractor emit
visibility_type: normal (the default) or skip it like it does effective_type when it equals base_type?
- Same question for
display_name when it equals Metabase's auto-humanized form of the column name.
entity_type defaults — null vs entity/GenericTable?
Happy to send a PR if there's interest in the direction.
Summary
The Metabase API supports a number of settable attributes on fields and tables — visibility, display name, search behavior, etc. — but
core-spec/v1/spec.mddoesn't list them, so the extractor doesn't emit them and the format can't round-trip them. Anyone wanting to manage these from a YAML source of truth has to invent local extensions.Attributes proposed for inclusion
Field-level
visibility_typenormal|details-only|sensitive|hidden|retired. Drives whether the field appears in pickers and result tables.display_namepatient_id→Patient ID), so the extractor would want a "skip when auto-default" rule.has_field_valueslist|search|auto-list|none. Controls dropdown behavior.caveatspoints_of_interestpreview_displayjson_unfoldingcustom_positionTable-level
visibility_typehidden|technical|cruft. Null means visible.display_nameentity_typeentity/UserTable,entity/EventTable. Drives some Metabase-side semantic behavior.caveatspoints_of_interestWhy this matters
Without these in the spec, every consumer has to:
Adding them to the spec — and emitting them from
extract-table-metadatawhen set — would let teams manage the full visible metadata surface declaratively without forking the tool.Open questions
visibility_type: normal(the default) or skip it like it doeseffective_typewhen it equalsbase_type?display_namewhen it equals Metabase's auto-humanized form of the column name.entity_typedefaults — null vsentity/GenericTable?Happy to send a PR if there's interest in the direction.