fix: open alert and report links on metrics views without a time dimension

[dfliess]

Should the "Open in browser" link of an alert or report work on a metrics view without timeseries?

The UI only offers alerts and scheduled reports on explores with a time dimension (CreateAlert.svelte, DimensionHeader.svelte, PivotDisplay.svelte). But timeseries is optional, and alerts and reports written in YAML can target any metrics view. For those, the link never reaches the explore: mapQueryToDashboard always requests MetricsViewTimeRange (the TODO: handle non-timestamp dashboards from #4666), and the page stops on no time dimension specified for metrics view.

To reproduce: a metrics view without timeseries and an explore on it, an alert on that metrics view written as query: name: MetricsViewAggregation with annotations: explore: <explore>, then open the link in the alert email.

If it should, this is the fix I'd suggest. The mapper requests the time range summary only when the metrics view has a time dimension, as the explore state managers already do, and fillTimeRange skips when there is none. A request without dimensions no longer opens the time dimension details page on such a metrics view, since there is nothing to chart against. If alerts and reports are meant to require a time dimension, happy to close this and follow whatever you prefer instead.

Tests cover a metrics view without a time dimension for aggregation requests, in both the explore and pivot (report) states, and for comparison requests; they fail without the fix with "Failed to fetch time range summary.". They also assert that no time range summary is requested for it, and runTest now checks every emitted response, not just the last one. Checked on a self-hosted deployment: the link of an alert on a metrics view without timeseries opens the explore with the alert's rows, with and without a session, and the link of an alert on a metrics view with a time dimension opens as before.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

🤖 Generated with Claude Code