@oneuptime/common 13.0.8 → 14.0.0

package/UI/Components/EditionLabel/LicenseManager.ts

@@ -0,0 +1,119 @@
+import { JSONObject } from "../../../Types/JSON";
+import { ComponentType, ReactElement, ReactNode } from "react";
+
+/*
+ * The contract between the edition dialog (EditionLabel) and the Enterprise
+ * license management UI.
+ *
+ * EditionLabel only READS the license: it asks GET /global-config/license and
+ * shows what the answer says - the edition pill, the status, grace and trial
+ * notices, the version card. Everything that CHANGES the license lives in the
+ * Enterprise Edition (ee/AdminDashboard/License, under ee/LICENSE), because
+ * the routes it calls exist only in the Enterprise server: activating it with
+ * a key or an offline token, refreshing it from oneuptime.com, replacing it,
+ * and the seat usage and instance tables a master admin manages it by.
+ *
+ * The Dashboard and the Admin Dashboard hand that UI to EditionLabel as their
+ * LicenseManager plugin (src/Enterprise/EnterprisePlugins.ts). The Community
+ * stubs have none, and the login page passes none: there the dialog shows
+ * the license status only, and nobody is told to manage the license from it.
+ *
+ * The manager wraps the dialog rather than filling one spot inside it. Its
+ * sections land in three places in the dialog body (messages at the top, seat
+ * usage after the version card, the activation input near the bottom) and it
+ * drives the dialog's footer buttons, so EditionLabel gives it renderDialog
+ * and the manager calls it with those parts. It stays mounted while the
+ * dialog is closed, so what an admin typed and which input they chose
+ * survive closing and reopening the dialog.
+ *
+ * Types only: nothing here ships any license management code.
+ */
+
+/*
+ * How close the installation is to its licensed seats. "breached" also
+ * covers an enforced limit that is exactly full: new users are already
+ * refused there.
+ */
+export type SeatTone = "healthy" | "approaching" | "breached";
+
+// What EditionLabel knows about the license, read-only.
+export interface LicenseSnapshot {
+  /*
+   * The body of the last GET /global-config/license that succeeded, or null
+   * before the first one and after one that failed. A new object on every
+   * successful load, so a manager can tell that the license was (re)loaded.
+   */
+  payload: JSONObject | null;
+  isLoading: boolean;
+  // Why the last load failed; "" when it did not.
+  loadError: string;
+  /*
+   * A master admin, in a dialog that has a license manager. The server
+   * accepts license writes from a master admin only, so nobody else is
+   * offered them.
+   */
+  canManageLicense: boolean;
+  licenseValid: boolean;
+  // Enterprise Edition with no license yet, inside its first-run trial.
+  isUnlicensedTrial: boolean;
+  // A real license (not the trial) is valid and loaded: show what it covers.
+  showLicenseDetails: boolean;
+  // "" when the server did not say.
+  companyName: string;
+  // The stored license key; "" when there is none or the caller may not see it.
+  licenseKey: string;
+  userLimit: number | null;
+  // What oneuptime.com last counted across every instance on the license.
+  currentUserCount: number | null;
+  /*
+   * The seat figure everything is measured against: the live, enforced count
+   * when this installation enforces its seat limit, else currentUserCount.
+   */
+  effectiveUserCount: number | null;
+  isSeatLimitEnforced: boolean;
+  canAddMoreUsers: boolean;
+  seatTone: SeatTone;
+  // The percent of licensed seats in use, as the admin reads it (may exceed 100).
+  seatUsageDisplayPercent: number | null;
+  currentVersion: string;
+  latestVersion: string;
+  // currentVersion is a real release number that can be compared.
+  hasComparableVersion: boolean;
+}
+
+// What a manager adds to the dialog. Every part is optional.
+export interface LicenseManagerDialogParts {
+  // Top of the body: the outcome of the last license action.
+  messages?: ReactNode | undefined;
+  // After the version card: seat usage and the instances on the license.
+  usage?: ReactNode | undefined;
+  // Near the bottom of the body: the license key or offline token input.
+  activation?: ReactNode | undefined;
+  // The dialog's primary button, when the manager offers one.
+  submitButtonText?: string | undefined;
+  onSubmit?: (() => void) | undefined;
+  isSubmitting?: boolean | undefined;
+  disableSubmitButton?: boolean | undefined;
+  // Left of the footer: actions on a license that is already in place.
+  leftFooterElement?: ReactElement | undefined;
+}
+
+export interface LicenseManagerProps {
+  license: LicenseSnapshot;
+  isDialogOpen: boolean;
+  // Asks GET /global-config/license again; the pill and the dialog follow.
+  reloadLicense: () => Promise<void>;
+  /*
+   * Applies the seat fields (isSeatLimitEnforced, seatsInUse, canAddMoreUsers)
+   * a license write answers with, the same way the GET's are applied.
+   */
+  applySeatEnforcement: (payload: JSONObject) => void;
+  // Renders the dialog (nothing while it is closed) with the manager's parts.
+  renderDialog: (parts: LicenseManagerDialogParts) => ReactElement;
+}
+
+/*
+ * Must render renderDialog's result, and must not be React.lazy: it is
+ * mounted with the edition pill on every page, and the dialog is inside it.
+ */
+export type LicenseManagerComponent = ComponentType<LicenseManagerProps>;

package/UI/Components/Graphs/DayUptimeGraph.tsx

@@ -39,10 +39,52 @@ export interface UptimeBarDaySummary {
   incidents: Array<UptimeBarTooltipIncident>;
 }
 
+/*
+ * One day's reading, measured server-side.
+ *
+ * The bars used to be derived purely from the timeline rows the browser
+ * happened to receive, and those rows arrive under a cap that silently drops
+ * history (see MonitorStatusTimelineService.getDailyUptimeAggregate). A day
+ * whose rows were dropped is indistinguishable, client-side, from a day that
+ * was genuinely quiet - so the graph painted both as the status page's
+ * `defaultBarColor`, which is GREEN on the overwhelming majority of pages.
+ * The page then asserted uptime for periods it had no data for.
+ *
+ * A reading carries how much of the day was actually COVERED by data, which
+ * is the thing the browser cannot infer for itself.
+ */
+export interface DayReading {
+  dayStart: Date;
+  daySeconds: number;
+  /* Zero means nothing was ever recorded for this day. */
+  coveredSeconds: number;
+  statusDurations: Array<StatusDuration>;
+}
+
+/*
+ * A day nobody measured is not a colour the operator gets to choose.
+ *
+ * `defaultBarColor` is branding for an ordinary good day; letting it also
+ * stand for "we have no idea" is exactly the conflation that made a page with
+ * a green default claim uptime it never recorded, and a page with a grey
+ * default look unmonitored while it was passing every check. This is a fixed
+ * neutral, drawn with a hatch so it is still distinguishable in greyscale and
+ * to a colour-blind reader.
+ */
+export const NO_DATA_BAR_COLOR: Color = new Color("#9CA3AF");
+
 export interface ComponentProps {
   startDate: Date;
   endDate: Date;
   events: Array<Event>;
+  /*
+   * Server-measured coverage per day. When a day has a reading, it decides
+   * whether that day has data and what its durations are; the `events` array
+   * is then only used for incident overlays. When absent - the dashboard
+   * monitor page, which does not fetch the aggregate - the old event-derived
+   * behaviour applies unchanged.
+   */
+  dayReadings?: Array<DayReading> | undefined;
   height?: number | undefined;
   barColorRules?: Array<BarChartRule> | undefined;
   downtimeEventStatusIds?: Array<ObjectID> | undefined;
@@ -173,6 +215,20 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
     const startOfTheDay: Date = OneUptimeDate.getStartOfDay(todaysDay);
     const endOfTheDay: Date = OneUptimeDate.getEndOfDay(todaysDay);
 
+    /*
+     * The server's reading for this day, when the caller supplied one. It is
+     * matched by instant rather than by index: the window's first bucket is
+     * clipped to the window start, so bucket i is not necessarily day i.
+     */
+    const todaysReading: DayReading | undefined = (
+      props.dayReadings || []
+    ).find((reading: DayReading) => {
+      return (
+        reading.dayStart.getTime() >= startOfTheDay.getTime() &&
+        reading.dayStart.getTime() <= endOfTheDay.getTime()
+      );
+    });
+
     const todaysEvents: Array<Event> = props.events.filter((event: Event) => {
       let doesEventBelongsToToday: boolean = false;
 
@@ -274,32 +330,75 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       }
     }
 
+    /*
+     * Does this day have data at all?
+     *
+     * With a server reading, coverage is the answer and it is authoritative -
+     * the browser cannot tell a quiet day from a day whose rows were dropped
+     * by the fetch cap. Without one, fall back to the old test.
+     */
+    const hasDataForTheDay: boolean = todaysReading
+      ? todaysReading.coveredSeconds > 0
+      : todaysEvents.length > 0;
+
     // now check bar rules and finalize the color of the bar
 
-    const uptimePercentForTheDay: number =
-      totalUptimeInSeconds + totalDowntimeInSeconds > 0
+    /*
+     * The denominator is what was MEASURED, not the length of the day. A day
+     * only half covered - the day a monitor was created - reports the
+     * percentage of the half we watched rather than being marked down for the
+     * hours nobody was looking.
+     *
+     * The old expression ended in `: 100`, which said "no readings at all
+     * means a perfect day". That is the single line that let a status page
+     * assert uptime for a period it had no data for, so it is gone rather
+     * than adjusted: with no data there is no percentage.
+     */
+    const uptimePercentForTheDay: number = !hasDataForTheDay
+      ? 0
+      : totalUptimeInSeconds + totalDowntimeInSeconds > 0
         ? (totalUptimeInSeconds /
             (totalDowntimeInSeconds + totalUptimeInSeconds)) *
           100
         : 100;
 
-    for (const rules of props.barColorRules || []) {
-      if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
-        color = rules.barColor;
-        break;
+    /*
+     * Rules are skipped entirely on a day with no data. Otherwise a page
+     * configuring ">= 99% is green" would have that rule matched by a day
+     * nobody measured, which is the very claim this change removes. No-data
+     * outranks operator rules on purpose.
+     */
+    if (hasDataForTheDay) {
+      for (const rules of props.barColorRules || []) {
+        if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
+          color = rules.barColor;
+          break;
+        }
       }
     }
 
-    if (todaysEvents.length === 1 && !hasEvents) {
+    if (todaysEvents.length >= 1) {
       hasEvents = true;
     }
 
-    if (todaysEvents.length === 1) {
-      hasEvents = true;
-    }
+    /*
+     * THE FIX.
+     *
+     * This used to read: no events today, so paint `defaultBarColor`. That
+     * single line is how a status page claimed uptime for days it had no data
+     * for - `defaultBarColor` is green on the overwhelming majority of pages,
+     * and "no events" was true both for a quiet day and for a day whose rows
+     * the fetch cap had thrown away.
+     *
+     * Now the two are separated. A day with data but no events of its own is
+     * an ordinary good day and still gets the operator's colour. A day with
+     * no data gets the fixed no-data treatment and says so.
+     */
+    hasEvents = hasDataForTheDay;
 
-    if (todaysEvents.length === 0) {
-      hasEvents = false;
+    if (!hasDataForTheDay) {
+      color = NO_DATA_BAR_COLOR;
+    } else if (todaysEvents.length === 0) {
       color = props.defaultBarColor || Green;
     }
 
@@ -315,9 +414,18 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       className = "w-20 h-" + props.height;
     }
 
-    // Build status durations for tooltip
-    const statusDurations: Array<StatusDuration> = [];
-    for (const key in secondsOfEvent) {
+    /*
+     * Build status durations for the tooltip and the day dialog.
+     *
+     * A server reading wins: its durations are measured over the whole day
+     * server-side, while `secondsOfEvent` can only describe the rows this
+     * browser happened to receive.
+     */
+    const statusDurations: Array<StatusDuration> = todaysReading
+      ? todaysReading.statusDurations
+      : [];
+
+    for (const key in todaysReading ? {} : secondsOfEvent) {
       statusDurations.push({
         label: eventLabels[key] || "Unknown",
         seconds: secondsOfEvent[key] || 0,

package/UI/Components/ModelList/ModelList.tsx

@@ -37,6 +37,13 @@ export interface ComponentProps<TBaseModel extends BaseModel> {
   fetchRequestOptions?: RequestOptions | undefined;
   customElement?: ((item: TBaseModel) => ReactElement) | undefined;
   noItemsMessage: string;
+  /*
+   * Render nothing, rather than noItemsMessage (or its "No items found."
+   * fallback), when the list loads empty. For a caller that explains an empty
+   * list itself, e.g. from onListLoaded. A search that matches nothing still
+   * says so.
+   */
+  hideEmptyState?: boolean | undefined;
   headerField?: string | ((item: TBaseModel) => ReactElement) | undefined;
   onSelectChange?: ((list: Array<TBaseModel>) => void) | undefined;
   refreshToggle?: string | undefined;
@@ -260,7 +267,10 @@ const ModelList: <TBaseModel extends BaseModel>(
         {error ? <ErrorMessage message={error} /> : <></>}
         {isLoading ? <ComponentLoader /> : <></>}
 
-        {!isLoading && !error && searchedList.length === 0 ? (
+        {!isLoading &&
+        !error &&
+        searchedList.length === 0 &&
+        (Boolean(searchText) || !props.hideEmptyState) ? (
           <ErrorMessage
             message={
               searchText

package/UI/Components/MonitorGraphs/Uptime.tsx

@@ -2,9 +2,16 @@ import ComponentLoader from "../ComponentLoader/ComponentLoader";
 import ErrorMessage from "../ErrorMessage/ErrorMessage";
 import DayUptimeGraph, {
   BarChartRule,
+  DayReading,
   Event,
   UptimeBarDaySummary,
 } from "../Graphs/DayUptimeGraph";
+import { StatusDuration } from "../Graphs/UptimeDaySummary";
+import Dictionary from "../../../Types/Dictionary";
+import {
+  UptimeDayBucket,
+  UptimeStatusDuration,
+} from "../../../Types/StatusPage/UptimeDailyAggregate";
 import UptimeUtil from "./UptimeUtil";
 import Color from "../../../Types/Color";
 import CommonMonitorEvent from "../../../Utils/Uptime/MonitorEvent";
@@ -27,6 +34,17 @@ export interface ComponentProps {
   height?: number | undefined;
   barColorRules?: Array<StatusPageHistoryChartBarColorRule> | undefined;
   downtimeMonitorStatuses: Array<MonitorStatus> | undefined;
+  /*
+   * Server-measured per-day coverage for THIS monitor.
+   *
+   * The `items` array above arrives under a fetch cap that silently drops
+   * history, so it cannot answer "did we have data for this day". These
+   * buckets can. When absent the graph keeps its old event-derived
+   * behaviour, which is what the dashboard monitor page still uses.
+   */
+  uptimeBuckets?: Array<UptimeDayBucket> | undefined;
+  /* Statuses by id, so a bucket's durations can be given a name and colour. */
+  monitorStatuses?: Array<MonitorStatus> | undefined;
   defaultBarColor: Color;
   incidents?: Array<UptimeBarTooltipIncident> | undefined;
   onBarClick?: (
@@ -62,6 +80,56 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
     );
   }, [props.barColorRules]);
 
+  /*
+   * Turn the server's buckets into the graph's per-day readings, resolving
+   * each status id to the name and colour the page already knows.
+   */
+  const dayReadings: Array<DayReading> | undefined = useMemo(() => {
+    if (!props.uptimeBuckets) {
+      return undefined;
+    }
+
+    const statusById: Dictionary<MonitorStatus> = {};
+
+    for (const status of props.monitorStatuses || []) {
+      if (status.id) {
+        statusById[status.id.toString()] = status;
+      }
+    }
+
+    const downtimeIds: Array<string> = (
+      props.downtimeMonitorStatuses || []
+    ).map((status: MonitorStatus) => {
+      return status.id?.toString() || "";
+    });
+
+    return props.uptimeBuckets.map((bucket: UptimeDayBucket): DayReading => {
+      return {
+        dayStart: bucket.bucketStart,
+        daySeconds: bucket.daySeconds,
+        coveredSeconds: bucket.coveredSeconds,
+        statusDurations: bucket.statusDurations.map(
+          (duration: UptimeStatusDuration): StatusDuration => {
+            const statusId: string = duration.monitorStatusId.toString();
+            const status: MonitorStatus | undefined = statusById[statusId];
+
+            return {
+              label: status?.name || "Unknown",
+              seconds: duration.seconds,
+              color: status?.color || props.defaultBarColor,
+              isDowntime: downtimeIds.includes(statusId),
+            };
+          },
+        ),
+      };
+    });
+  }, [
+    props.uptimeBuckets,
+    props.monitorStatuses,
+    props.downtimeMonitorStatuses,
+    props.defaultBarColor,
+  ]);
+
   if (props.isLoading) {
     return <ComponentLoader />;
   }
@@ -80,6 +148,7 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
       startDate={props.startDate}
       endDate={props.endDate}
       events={events}
+      dayReadings={dayReadings}
       defaultBarColor={props.defaultBarColor}
       height={props.height}
       barColorRules={barColorRules}

package/UI/Components/TelemetryViewer/TelemetryViewer.tsx

@@ -33,6 +33,18 @@ export interface TelemetryViewerProps<T> {
   error?: string | undefined;
   onRefresh?: (() => void) | undefined;
   emptyMessage?: string | undefined;
+  /*
+   * Replaces the default "No results / try adjusting filters" block when the
+   * list comes back empty.
+   *
+   * For most signals the default is right: an empty list means the filters
+   * are too narrow. For a signal that a project may not be SENDING at all,
+   * it is usually wrong — the reader needs the setup guide, not an
+   * invitation to widen a time range over data that does not exist. Takes
+   * precedence over `emptyMessage`; nothing is rendered around it, so the
+   * caller owns the whole empty area.
+   */
+  emptyContent?: ReactNode;
 
   // -- Layout --
   /** Render one item row in the main list. */
@@ -296,18 +308,22 @@ function TelemetryViewerInner<T>(props: TelemetryViewerProps<T>): ReactElement {
                   <ComponentLoader />
                 </div>
               ) : props.items.length === 0 ? (
-                <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
-                  <Icon
-                    icon={IconProp.Search}
-                    className="h-8 w-8 text-gray-300"
-                  />
-                  <p className="text-sm font-medium text-gray-500">
-                    {props.emptyMessage || "No results"}
-                  </p>
-                  <p className="text-xs text-gray-400">
-                    Try adjusting filters or time range.
-                  </p>
-                </div>
+                props.emptyContent !== undefined ? (
+                  <>{props.emptyContent}</>
+                ) : (
+                  <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
+                    <Icon
+                      icon={IconProp.Search}
+                      className="h-8 w-8 text-gray-300"
+                    />
+                    <p className="text-sm font-medium text-gray-500">
+                      {props.emptyMessage || "No results"}
+                    </p>
+                    <p className="text-xs text-gray-400">
+                      Try adjusting filters or time range.
+                    </p>
+                  </div>
+                )
               ) : (
                 <ul className="divide-y divide-gray-100">
                   {props.items.map((item: T, index: number) => {