feat: question update --db; fix Slack alerts/notifications for v0.59+

[parikshit223933]

Summary

Two related gaps that together make it impossible to use the CLI for two pretty common Metabase v0.59+ workflows:

1. Moving a saved card to a different database — question update lets you change name, SQL, display, viz, template tags… but not the underlying database. Setting database_id alone on PUT /api/card/{id} silently leaves dataset_query.database pointing at the old DB and the card keeps running against the original source.
2. Setting up a Slack alert — alert create --channel-type slack is rejected by v0.59+ Metabase with 400 Bad Request: {"specific-errors":{"handlers":[{"channel_type":["unknown error, received: :slack"]}]}}. Three coupled issues — wrong channel_type literal, no way to specify a Slack channel name, schedule attached to the wrong field — make Slack alerts unreachable from the CLI.

What changes

question update --db <id>

New flag on question update. Updates both the top-level database_id and dataset_query.database in one PUT, so the two never drift. Pure helper applyDatabaseToDatasetQuery covers v0.59+ stages and legacy native shapes; new tests assert both.

metabase-cli question update 24355 --db 35 --sql-file ch.sql --unsafe

Slack alerts / notifications

Three coupled fixes against /api/notification:

Bug	Fix
channel_type sent as bare "slack" / "email" (rejected by v0.59+)	canonicalizeChannelType() accepts bare or prefixed input and emits channel/slack / channel/email
recipients hardcoded to notification-recipient/user (can't address a Slack channel by name)	New --slack-channel <name> flag emits a notification-recipient/raw-value with details.value: "#channel"
--schedule <cron> was attached to handlers[].schedule (silently ignored)	Schedule now mounted at top-level subscriptions[] as notification-subscription/cron; new --schedule-type / --schedule-hour fall through to cron for legacy callers

Also wired through the renamed payload fields: alert_condition + alert_above_goal → send_condition (has_result / goal_above / goal_below), alert_first_only → send_once. Legacy field names are still accepted as CLI input.

metabase-cli alert create \
  --card 42 \
  --condition rows \
  --channel-type slack \
  --slack-channel "#alerts" \
  --schedule "0 0 * * * ?"        # Quartz cron — hourly on the hour

Verified end-to-end against v0.59.4 (d4fb593)

Reproducing the original unknown error, received: :slack 400 on main, then running the new code against the same instance:

$ metabase-cli alert create --card 24355 --condition rows \
    --channel-type slack --slack-channel "#nsdc-assessment-alert" \
    --schedule "0 0 * * * ?"
Alert #58 created.

$ metabase-cli alert show 58
handlers: [{
  channel_type: "channel/slack",
  recipients: [{
    type: "notification-recipient/raw-value",
    details: { value: "#nsdc-assessment-alert" }
  }]
}]
subscriptions: [{
  type: "notification-subscription/cron",
  cron_schedule: "0 0 * * * ?"
}]
payload: { send_condition: "has_result", send_once: false }

And the database swap:

$ metabase-cli question update 24355 --db 35 --unsafe
Question #24355 ... updated.

$ metabase-cli question show 24355  # both fields now consistent
database_id            : 35
dataset_query.database : 35

Tests

Full suite stays green: 142 passing (138 baseline + 4 new).

• New: applyDatabaseToDatasetQuery on v0.59+ stages and legacy native shapes; refuses to mutate input.
• New: AlertApi.create regression that asserts channel/slack + raw-value Slack recipient + top-level notification-subscription/cron on the outgoing body.
• Updated: AlertApi.create / AlertApi.update tests reflect the renamed send_condition / send_once fields.

Test Files  9 passed (9)
     Tests  142 passed (142)

Lint passes; build succeeds.

Back-compat

• --channel-type slack (bare) still works — internally canonicalized to channel/slack.
• Legacy schedule_type / schedule_hour still work — translated to Quartz cron for the new subscriptions[] shape.
• Legacy alert_condition / alert_first_only still accepted as CLI input — mapped to send_condition / send_once inside AlertApi.
• Existing card payloads without a --db flag are unchanged.

🤖 Generated with Claude Code