Preview Widget

The query half of a persisted Widget.config.

A widget embeds a ReportQuery rather than naming one, so this is that same query MINUS its identity (key/version) and minus time_dimension (which the referenced measures own and import validation pins — a widget never restates it). Same field TYPES throughout, so the two cannot describe different vocabularies.

extra="allow" is deliberate and is the line this model draws:

• The QUERY half is strict. A bad group_by or an unresolvable ref produces a wrong number silently, on a human's screen, inside a report an agent said was correct. That must fail at the boundary.
• PRESENTATION keys (show_na, table_orientation, bar_mode, row_groups, column_colors, group_colors, sticky_first_column, legendPosition — note the one camelCase legacy key) ride along unmodelled. Locking them down would 422 real stored configs to protect against a wrong COLOUR, which is not the failure mode worth guarding.

Near-miss metric keys (metric_ref for metric_refs) and catalog-shaped entries are coerced by :func:coerce_widget_config_metric_refs before the query half is validated, so a find_metric hit pasted verbatim is accepted. Nested config.metric_refs / spec.metric_refs hoist the same way (#2457). A config that still has no metrics after that rewrite is rejected.

Input spec for run_widget_query.

ACL context (PR3, all optional/additive — the "then required" tightening is a later frontend migration): dashboard_id + widget_id identify a placed widget so the endpoint authorizes can_view against that dashboard's category; category_id is the target tab for a live preview, authorized against can_edit. When none are set the spec is a free-form query with no category ACL (documented limitation — see access.py).

Response from the query engine.