/* Live-Statusübersicht widget (concept doc §7) - status-overview.html.twig.
   Same shapes/treatment as user-dashboard's Info widget and sensor-widgets'
   own compact_controls widgets - see each of their own CSS files for the
   sibling rules this mirrors. */

/* .mon-status-overview__status is a real <a> now (status-overview.html.twig -
   links to /app/monitoring's Incidents tab), not styled text - reset the
   default link underline/color here so the --summary--* modifiers below
   (and the plain "Loading…"/"No devices" state, which carries no modifier
   class) still fully own its appearance. */
.mon-status-overview__status {
  display: block;
  color: var(--dash-muted);
  text-decoration: none;
}
.mon-status-overview__status:hover {
  text-decoration: underline;
}

/* Summary banner (built in JS - see render()'s summary logic): "all OK"
   or "N devices with open issues", toned by the worst severity present.
   Reuses Bootstrap's own *-bg-subtle/*-text-emphasis theme variables
   (already dark/light-mode aware) rather than hand-rolled colors - same
   fallback idiom user-dashboard's own dashboard.css uses for
   .dashboard-add__item--danger:hover (var(--bs-danger-bg-subtle,
   var(--dash-border))). */
.mon-status-overview__summary {
  display: flex;
  align-items: center;
  gap: 0.4rem;
  padding: 0.45rem 0.75rem;
  margin-bottom: 0.5rem;
  border-radius: 0.4rem;
  font-size: 0.85rem;
  font-weight: 600;
}
.mon-status-overview__summary--ok {
  background: var(--bs-success-bg-subtle, var(--dash-border));
  color: var(--bs-success-text-emphasis, var(--dash-text));
}
.mon-status-overview__summary--info {
  background: var(--bs-info-bg-subtle, var(--dash-border));
  color: var(--bs-info-text-emphasis, var(--dash-text));
}
.mon-status-overview__summary--warning {
  background: var(--bs-warning-bg-subtle, var(--dash-border));
  color: var(--bs-warning-text-emphasis, var(--dash-text));
}
.mon-status-overview__summary--critical {
  background: var(--bs-danger-bg-subtle, var(--dash-border));
  color: var(--bs-danger-text-emphasis, var(--dash-text));
}

/* Rows are sorted worst-first in JS (render()) - the colored left border +
   dot give the eye a scan line down the card edge, and OK rows are
   deliberately dimmed (opacity) so the few rows that actually need
   attention are what stands out, not a wall of uniform green pills.

   `.mon-status-overview__list` is prefixed onto `display: flex` here
   (rather than a bare `.mon-status-overview__row` rule) purely to win the
   specificity tie against Bootstrap's own `.list-group-item { display:
   block }` (same 1-class specificity, so whichever stylesheet happens to
   load later would otherwise win, which was silently collapsing every
   row back to block/inline flow - the badge sitting right next to the
   device name instead of pushed to the row's end, since `flex: 1 1 auto`
   on .mon-status-overview__device has nothing to push against without
   `display: flex` actually applying). */
.mon-status-overview__list .mon-status-overview__row {
  display: flex;
  align-items: center;
  gap: 0.6rem;
  padding: 0.45rem 0.75rem;
  border-left: 3px solid transparent;
  transition: background-color 0.15s ease;
}
.mon-status-overview__row:hover {
  background: var(--dash-border);
}
.mon-status-overview__row--ok {
  opacity: 0.7;
}
.mon-status-overview__row--info {
  border-left-color: var(--bs-info);
}
.mon-status-overview__row--warning {
  border-left-color: var(--bs-warning);
}
.mon-status-overview__row--critical {
  border-left-color: var(--bs-danger);
}

.mon-status-overview__dot {
  flex: 0 0 auto;
  width: 0.45rem;
  height: 0.45rem;
  border-radius: 50%;
  background: var(--bs-success);
}
.mon-status-overview__row--info .mon-status-overview__dot {
  background: var(--bs-info);
}
.mon-status-overview__row--warning .mon-status-overview__dot {
  background: var(--bs-warning);
}
.mon-status-overview__row--critical .mon-status-overview__dot {
  background: var(--bs-danger);
}

.mon-status-overview__device {
  flex: 1 1 auto;
  min-width: 0;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  color: var(--dash-text);
  text-decoration: none;
  font-size: 0.88rem;
}
.mon-status-overview__device:hover,
.mon-status-overview__device:focus {
  text-decoration: underline;
}

.mon-status-overview__badge {
  flex: 0 0 auto;
  font-size: 0.7rem;
  font-weight: 600;
}

/* "Active <2h ago>" next to the badge (render() in
   monitoring-status-overview.js) - muted/small, sits between the device
   link and its severity badge. */
.mon-status-overview__age {
  flex: 0 0 auto;
  font-size: 0.72rem;
  color: var(--dash-muted);
  white-space: nowrap;
}

/* No positioning/opacity rules of its own - on init, dashboard.js
   physically moves this button out of the card body and into the shared
   .dashboard-widget__controls header row (see this widget's own
   compact_controls catalog entry and user-dashboard's README section 13),
   where .dashboard-widget__controls button already styles it identically
   to the collapse/hide buttons next to it - same treatment
   .dashboard-info__settings-toggle gets in user-dashboard's own
   dashboard.css. */
.mon-status-overview__settings-toggle {
  display: flex;
  align-items: center;
}

/* .mon-status-overview__settings is the outer Bootstrap `.modal` element
   itself (see this widget's own template) - no layout rules of its own,
   Bootstrap fully owns its display/position/backdrop toggling. */
.mon-status-overview__settings-body {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
  text-align: left;
}
.mon-status-overview__field {
  display: flex;
  flex-direction: column;
  gap: 0.2rem;
}
.mon-status-overview__field label {
  font-size: 0.75rem;
  color: var(--dash-muted);
}
.mon-status-overview__widget-controls {
  display: flex;
  gap: 0.4rem;
}

/* -------------------------------------------------------------------- */
/* /app/monitoring - the consolidated page (templates/monitoring.html.twig) */
/* -------------------------------------------------------------------- */

/* The --dash-* custom properties above are defined by user-dashboard's own
   dashboard.css, loaded only on template === 'dashboard' (see that
   plugin's onTwigSiteVariables()) - not on this page. Rather than
   duplicating its actual color choices here, alias the same variable
   names to Bootstrap's own already-global, already-theme-aware tokens so
   the .mon-status-overview markup this page reuses for its Live tab
   renders identically wherever it appears, with no color values owned by
   another plugin duplicated. Scoped to .mon-app's own descendants only -
   never touches :root, so it can't affect the dashboard page itself. */
.mon-app {
  --dash-text: var(--bs-body-color);
  --dash-muted: var(--bs-secondary-color);
  --dash-border: var(--bs-border-color);
  /* table-striped/table-hover on the Rules/Incidents tables (monitoring.html.twig) -
     same fix sensor-widgets.css already applies for its own Log/Inspector
     DataTables (.sw-log__table-wrap/.sw-inspector__table-wrap - see that
     rule's own docblock): DataTables' Bootstrap5 integration CSS hardcodes
     --dt-row-stripe/--dt-row-hover to plain black/white rather than
     reusing Bootstrap's own --bs-secondary-rgb, so alternating/hover rows
     render as an untinted grey instead of tracking the theme. These
     custom properties inherit down the DOM, so setting them here on the
     page's own wrapper covers both tables without touching the vendored
     file or duplicating sensor-widgets' own rule.
  */
  --dt-row-stripe: var(--bs-secondary-rgb);
  --dt-row-hover: var(--bs-secondary-rgb);
}

/* Tab bar + its per-tab action area (monitoring.html.twig) - tabs on the
   left, whichever tab-specific action is relevant ("+ Neue Regel", the
   Incidents refresh control) right-aligned on the SAME row, not a
   separate row below it. Bootstrap's own .nav-tabs bottom border is "the
   line" these actions now sit on top of/next to, rather than under. */
.mon-app__tabbar {
  display: flex;
  align-items: flex-end;
  justify-content: space-between;
  gap: 1rem;
  flex-wrap: wrap;
  margin-bottom: 1rem;
}
.mon-app__tabs {
  margin-bottom: 0;
  border-bottom: none;
}
.mon-app__tab-actions {
  display: flex;
  align-items: flex-end;
  padding-bottom: 0.25rem;
}
/* Only one of [data-mon-tab-action] is ever un-hidden at a time
   (activateTab() in monitoring-app.js), each stacking its own controls
   vertically - refresh row, then the last-updated line below it, exactly
   the shape sensor-widgets' Filter widget uses for the same two pieces. */
.mon-app__tab-actions > div {
  display: flex;
  flex-direction: column;
  align-items: flex-end;
  gap: 0.3rem;
}

/* Incidents tab's auto-refresh control (monitoring.html.twig) - Bootstrap's
   .input-group defaults to width: 100%, which is right inside the Filter
   widget's own narrow sidebar column (its original context) but stretches
   oddly wide here since the tab-actions area is a page toolbar, not a
   dashboard card. Capped so it stays compact and right-aligned; not
   copying .sw-filter__controls' own flex-basis rule since that's tuned
   for stacking 3 widget-card controls responsively, not a fit for one
   control in a page's tab bar. */
.mon-app__refresh-group {
  max-width: 220px;
}

/* Mirrors .sw-filter__last-updated (sensor-widgets.css) visually - see
   this element's own docblock in monitoring.html.twig for why it's a
   separate class rather than reusing that one directly (alias the LOOK,
   don't couple the markup to another plugin's class name - same idea
   .mon-app's own --dash-* aliasing above already uses). */
.mon-app__last-updated {
  font-size: 0.8rem;
  font-weight: 600;
  color: var(--bs-secondary-color);
  cursor: pointer;
}
.mon-app__last-updated:hover {
  text-decoration: underline;
  color: var(--bs-body-color);
}
.mon-app__last-updated--stale {
  color: var(--bs-danger);
  font-weight: 700;
}

/* Incidents tab's Device/Schweregrad/Status filter row. */
.mon-app__filters {
  display: flex;
  gap: 0.5rem;
  margin-bottom: 0.75rem;
  flex-wrap: wrap;
}
.mon-app__filters select {
  max-width: 200px;
}

.mon-app__status {
  color: var(--bs-secondary-color);
  padding: 0.5rem 0;
}

.mon-app__table th {
  font-size: 0.8rem;
  text-transform: uppercase;
  color: var(--bs-secondary-color);
  font-weight: 600;
}
.mon-app__table td {
  vertical-align: middle;
}

/* Icon-only action buttons (Edit/Delete/Ack/Resolve/the active-incident
   marker, all built in monitoring-app.js) - flexbox-centers the icon
   glyph in both directions instead of trusting the icon font's own
   baseline/line-height, which was leaving it visibly a couple px high
   confirmed live across every one of these buttons, not just one. More
   robust than a vertical-align tweak (font-metric-dependent, fragile if
   the icon or button size ever changes) since flex centering doesn't
   care what the glyph's own baseline is. */
.mon-app__table td .btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Rule wizard modal (#mon-wizard) */
.mon-wizard__status {
  min-height: 1.2rem;
  color: var(--bs-danger);
  font-size: 0.85rem;
}
.mon-wizard__step + .mon-wizard__step {
  margin-top: 0.75rem;
}
.mon-wizard__step label {
  display: block;
  font-size: 0.8rem;
  color: var(--bs-secondary-color);
  margin-bottom: 0.25rem;
}
.mon-wizard__row {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 0.75rem;
}
.mon-wizard__row--inline {
  grid-template-columns: auto 1fr;
  align-items: center;
  gap: 0.5rem;
}

/* Phase 3: the optional "Vorlage" field at the top of the device step -
   [hidden] when plugins.monitoring.rule_templates is empty (see
   populateTemplatePicker() in monitoring-app.js), separated visually from
   the device select below it since it's a distinct, optional decision. */
.mon-wizard__field {
  margin-bottom: 1rem;
  padding-bottom: 0.75rem;
  border-bottom: 1px solid var(--bs-border-color);
}

/* Device/group toggle (see the twig template's own comment on it) - sits
   right above the device/group <select> it controls. [hidden] by default,
   shown by JS only for a caller with sensor-widgets.device_groups. */
.mon-wizard__target-toggle {
  display: flex;
  margin-bottom: 0.75rem;
}

/* Phase 3: composite (AND/OR) condition rows - one per sub-condition,
   cloned from #mon-wizard ​[data-mon-wizard-composite-row-template] by
   addCompositeRow() in monitoring-app.js. */
[data-mon-wizard-composite-rows] {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
  margin: 0.5rem 0 0.75rem;
}
.mon-wizard__composite-row {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
  padding: 0.6rem;
  border: 1px solid var(--bs-border-color);
  border-radius: 0.375rem;
}
.mon-wizard__composite-row-head {
  display: flex;
  align-items: center;
  gap: 0.5rem;
}
.mon-wizard__composite-row-head select[data-mon-wizard-composite-kind] {
  flex: 1 1 auto;
}
.mon-wizard__composite-row-head [data-mon-wizard-composite-remove] {
  flex: 0 0 auto;
}
/* Same shape as the main threshold step (.mon-wizard__step[data-mon-wizard-step="threshold-fields"]) -
   metric select full-width on its own line, operator+value as a 2-column
   row below it via the shared .mon-wizard__row class. */
.mon-wizard__composite-row-fields {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
}