Found in the v0.2.0 cross-surface audit. Minor UX correctness bug, not a security or data issue.
The new-notification-channel form renders an Enabled checkbox (services/api/src/admin.html:11350) and the create payload includes enabled (admin.html:11573, sent at :11594). But CreateChannelRequest (services/api/src/notifications.rs:470-490) has no enabled field, so serde drops it, and create hardcodes enabled: true (notifications.rs:653). An operator who unchecks Enabled while creating a channel gets an enabled channel anyway.
The update PUT does accept enabled, so toggling after creation works.
Fix (either): drop the Enabled checkbox from the create form, or add an enabled field (default true) to CreateChannelRequest and honor it in create. The latter matches the form's apparent intent.
Found in the v0.2.0 cross-surface audit. Minor UX correctness bug, not a security or data issue.
The new-notification-channel form renders an Enabled checkbox (
services/api/src/admin.html:11350) and the create payload includesenabled(admin.html:11573, sent at:11594). ButCreateChannelRequest(services/api/src/notifications.rs:470-490) has noenabledfield, so serde drops it, and create hardcodesenabled: true(notifications.rs:653). An operator who unchecks Enabled while creating a channel gets an enabled channel anyway.The update PUT does accept
enabled, so toggling after creation works.Fix (either): drop the Enabled checkbox from the create form, or add an
enabledfield (default true) toCreateChannelRequestand honor it in create. The latter matches the form's apparent intent.