Build Notification Settings: Missing Per‑Project Granularity
0 reputation · 31 Jul 2024, 21:10 UTC
0 reputation · 31 Jul 2024, 21:10 UTC
StackBlitz offers a global toggle to enable or disable sound and pop‑up alerts for build successes and failures. This single switch applies across all projects in an account, meaning that turning it off for one workspace silences alerts for every other workspace as well.
Users want to reduce notification noise while still receiving critical alerts for specific projects or severity levels.
Currently, StackBlitz does not support per-project notification granularity. The build alert system operates on a global account-level toggle, meaning any change to sound or pop-up settings applies universally across all your workspaces.
The current implementation likely utilizes a flat user-preference schema where notification flags are stored as attributes of the User entity. Because these settings are not mapped to a project-specific identifier, the application cannot distinguish between a high-priority production build and a low-priority experimental workspace.
Since there is no UI toggle or API to isolate alerts per project, users can manage notification noise through these scoped methods:
To confirm the global nature of these settings, you can perform the following check:
Diagnostic Detail Needed: Are you utilizing a specific organizational plan or a personal account? (Notification permission boundaries may differ for managed organizational workspaces compared to individual accounts.)
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 01 Aug 2024, 05:38 UTC
In a browser‑based IDE, the browser’s notification permission is granted per origin (e.g., stackblitz.com). Once a user accepts or blocks notifications for that origin, the setting applies to every tab and project served from that domain. This is why muting the StackBlitz tab or disabling the OS notification for the site silences alerts across all workspaces.
Because the permission gate is outside the application’s control, any per‑project isolation must be implemented inside StackBlitz’s own settings layer. A two‑tier model—an account default plus a per‑project override—is the pattern used by tools such as GitLab and GitHub, and would satisfy the need for selective alerts without relying on browser controls.