Fix test alerts using default alert instead of selected custom overlay/layout #35

New issue

Closed

opened 2026-06-03 20:11:46 -05:00 by Gitchegumi · 0 comments

Gitchegumi commented

2026-06-03 20:11:46 -05:00

(Migrated from github.com)

Problem

When creating a custom overlay/layout with uploaded assets, pressing the test button still fires the default alert instead of the custom overlay/layout.

This makes it hard to validate whether a custom layout actually works and breaks trust in the editor/dashboard behavior.

Expected behavior

When a user presses a test button from a layout/config context, the test alert should render using the selected custom overlay/layout and its assigned assets/settings.

Current behavior

A custom overlay/layout can be created with uploaded assets.
Pressing the test button fires the default alert instead of the custom layout.

Areas to inspect

Manual/test alert API payload.
Alert config to layout mapping.
Overlay profile routing/display key handling.
Event payload fields related to layoutId, layoutName, visual asset, sound asset, duration, volume, and template text.
Client-side test button code to ensure it sends the selected layout/config context.
Server-side fallback logic that may be choosing the default layout too aggressively.

Acceptance criteria

Test alerts fired from a custom layout use that custom layout.
Uploaded visual/sound assets attached to the custom layout are included in the test event.
Default layout is used only when no custom layout/config is selected.
The response/event payload contains enough layout metadata for the overlay route to render the intended layout.
Add regression coverage for custom layout test behavior if the existing test structure supports it.

Notes

This is separate from building a full drag-and-drop overlay editor. This issue is about making the current custom layout/test-alert behavior use the selected custom overlay instead of falling back to the default alert.

## Problem When creating a custom overlay/layout with uploaded assets, pressing the test button still fires the default alert instead of the custom overlay/layout. This makes it hard to validate whether a custom layout actually works and breaks trust in the editor/dashboard behavior. ## Expected behavior When a user presses a test button from a layout/config context, the test alert should render using the selected custom overlay/layout and its assigned assets/settings. ## Current behavior - A custom overlay/layout can be created with uploaded assets. - Pressing the test button fires the default alert instead of the custom layout. ## Areas to inspect - Manual/test alert API payload. - Alert config to layout mapping. - Overlay profile routing/display key handling. - Event payload fields related to `layoutId`, `layoutName`, visual asset, sound asset, duration, volume, and template text. - Client-side test button code to ensure it sends the selected layout/config context. - Server-side fallback logic that may be choosing the default layout too aggressively. ## Acceptance criteria - Test alerts fired from a custom layout use that custom layout. - Uploaded visual/sound assets attached to the custom layout are included in the test event. - Default layout is used only when no custom layout/config is selected. - The response/event payload contains enough layout metadata for the overlay route to render the intended layout. - Add regression coverage for custom layout test behavior if the existing test structure supports it. ## Notes This is separate from building a full drag-and-drop overlay editor. This issue is about making the current custom layout/test-alert behavior use the selected custom overlay instead of falling back to the default alert.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gitchegumi/GitchAlerts#35

No description provided.

Rows
Columns