ProxMenux v1.2.1.4 (Beta)

Fourth beta of the v1.2.1.x cycle. This release ships two
operator-facing improvements that close gaps reported on the
community channels: a granular dismiss flow for Health Monitor
alerts — so a single intentionally-full storage no longer has to
silence an entire category every 24 hours — and full feature parity
for the Apprise notification channel, which now exposes the same
per-event toggles / Quiet Hours / Daily Digest controls as
Telegram, Gotify, Discord and Email. Also fixes a mobile layout
regression in the Apprise settings tab.

Main changes in v1.2.1.4

Per-error dismiss duration — 24 hours, 7 days, or Permanently

Reported on the community channel by a user with an LVM partition
that's full on purpose: every 24 hours the storage CRITICAL
alert came back and the only way to make it stop was to silence the
entire Storage Mounts & Space category for everything else on
the host as well. Dismiss used to be a single action with a single
duration (the category's configured suppression). Now the Dismiss
button on each Health Monitor alert opens a small dropdown with
three options:

• 24 hours — the previous default, behaves exactly as before.
• 7 days — handy for a temporary condition you don't want to
  hear about during a week-long migration.
• Permanently — silences this specific error_key indefinitely.
  Persisted as suppression_hours = -1 in the persistence DB, never
  re-emits and never re-notifies. Marked with a distinct amber
  🔒 Permanent badge in the Health Monitor so the operator can
  always see which alerts are intentionally silenced.

The backend already supported a permanent-suppression sentinel — the
infrastructure just lacked a UI to set it. The accompanying API
change is small and backwards-compatible:
POST /api/health/acknowledge accepts an optional
suppression_hours body field (positive integer for hours; -1 for
permanent). Omitting the field keeps the existing behaviour
verbatim — the call uses the category's configured suppression.

A second new endpoint POST /api/health/un-acknowledge {error_key}
clears a previously-recorded acknowledgment, so the alert becomes
eligible to fire again on the next scan if the underlying condition
is still present. Used by the new Settings panel below.

Active Suppressions panel — audit log + Re-enable, in Settings

The dismiss dropdown above introduces a need: once a user has
permanently silenced an alert, they need a place to find it again
and un-dismiss it if circumstances change (the disk is being
replaced, the LXC's full pool got resized, the manually-stopped
service was brought back, etc.). A new card lands in
Settings → Health Monitor, between Suppression Duration and
Remote Storage Exclusions:

• Lists every currently-dismissed alert — both time-limited
  dismisses (with a remaining-time badge like 22h remaining or
  6d remaining) and permanent dismisses (with the 🔒 Permanent
  badge from the Health Monitor).
• Each row carries the error_key, the category, the original
  severity and the timestamp the dismiss was recorded — enough
  context to recognise the alert without having to triangulate
  from the Health Monitor itself.
• Every row has a Re-enable button that clears the
  acknowledgment server-side. The action is gated by the Health
  Monitor's Edit toggle at the top of the page, matching the
  rest of the Health settings — toggle Edit first, then the
  button becomes active.
• Permanent dismisses can only be reverted from here. The
  Health Monitor itself doesn't expose a per-alert un-dismiss
  affordance to avoid accidental re-enables; the Settings panel is
  the deliberate audit + revert surface for them.
• Time-limited dismisses are also listed and can be force-revived
  from this panel without waiting for their countdown to expire.

Apprise — per-event toggles, Quiet Hours and Daily Digest

The Apprise tab was the only notification channel without the
per-event toggles, Quiet Hours and Daily Digest controls that the
other channels (Telegram, Gotify, Discord, Email) all carry. The
backend's per-channel filtering already applied generically to
every channel including Apprise via the channel_overrides block —
the UI just wasn't surfacing the same controls. The Apprise tab now
exposes:

• The full Notification Categories block — same 10 categories
  with their sub-event toggles, identical to the other channels.
• Quiet Hours — start/end window, with the same per-channel
  buffering behaviour (events fired during the window are persisted
  and released as a grouped summary when the window closes).
• Daily Digest — opt-in daily summary delivery at a chosen time.

The same Send Test button stays at the bottom of the section.

Apprise URL row — mobile overflow fixed

On narrow viewports the Enable Apprise → Apprise URL row used to
push past the right edge of the viewport, breaking the layout for
the entire Notifications card. Two contributing causes:

• The placeholder string packed four full example URLs into a
  single line (tgram://bottoken/ChatID · ntfy://server/topic · discord://webhook_id/token · matrix://...), which the browser
  could not wrap inside an <input> field — it just clipped the
  visible portion and let the input itself overflow the container
  on mobile where the container width fell below the natural width.
• The "Examples: tgram://, discord://, slack://, ntfy://,
  matrix://, pushover://, mailto://" paragraph used inline <code>
  tokens with no break-all rule, so when the viewport was tight
  enough that the natural commas/spaces couldn't accommodate the
  line, the whole row scrolled horizontally instead of wrapping.

The placeholder is now a single concise example
(tgram://bottoken/ChatID), the URL input wrapper enforces
min-w-0 / flex-1 / shrink-0 on its children, and the examples
paragraph uses break-all min-w-0 so it wraps cleanly at any
viewport width.

Thanks to @maragath on the community channel for the dismiss
report that drove the per-error dismiss work, and to the testers
who reported the Apprise mobile breakage. Feedback is welcome on
the same channels.