@oneuptime/common 12.0.32 → 12.0.33

package/Utils/NetworkDevice/DeviceHealthStateUtil.ts

@@ -1,6 +1,7 @@
 import DeviceReachabilityUtil, {
   NetworkDeviceReachability,
 } from "./DeviceReachabilityUtil";
+import { NetworkDeviceMonitoringMethodUtil } from "../../Types/NetworkDevice/NetworkDeviceMonitoringMethod";
 
 /*
  * The one place that decides how healthy a single NetworkDevice is, and how
@@ -15,10 +16,12 @@ import DeviceReachabilityUtil, {
  *
  * So the rule moves here, and both halves read it:
  *
- *   status  — a monitor-stamped status wins outright; otherwise the shared
- *             reachability rule (the OUTCOME of the last poll, never its
- *             age) decides, and a device nothing has ever polled is
- *             `unknown` rather than a failure.
+ *   status  — for a MONITOR-BACKED device the stamped monitor status is the
+ *             verdict; for a probe-polled device the shared reachability
+ *             rule (the OUTCOME of the last poll, never its age) decides and
+ *             the stamp is informational only (see the input docs); a device
+ *             nothing has ever polled — or a monitor-backed device nothing
+ *             has yet reported on — is `unknown` rather than a failure.
  *   degraded — an up device with dark ports. A switch that answers every
  *             poll while three of its interfaces are down is not down, but
  *             it is exactly what somebody is looking for.
@@ -55,9 +58,18 @@ export type NetworkDeviceHealthState =
  * The columns the classifier reads. Every caller selects exactly these.
  *
  * `monitorStatusIsOffline` is the OFFLINE end of the device's stamped
- * MonitorStatus row — `undefined` when no monitor backs the device (the
- * ordinary case for an SNMP-walked switch), which is what sends the
- * decision down to reachability.
+ * MonitorStatus row — `undefined` when nothing has stamped one, which is
+ * what sends the decision down to reachability.
+ *
+ * It is CONSULTED ONLY FOR A MONITOR-BACKED DEVICE (monitoringMethod
+ * "Monitor"). A probe-polled device can carry a stamp too — a Network
+ * Device monitor watching its walk writes one, and an "interface down →
+ * Offline" criterion will happily stamp Offline on a switch that answers
+ * every ping — but its health source is the poll: `isReachable` is what its
+ * pill, the summary tiles and the Status chip all read, and a classifier
+ * that let the stamp outrank it would colour the site card and the map red
+ * over a device whose own row reads Up. So for a probe-polled device the
+ * stamp stays informational and reachability decides.
  *
  * The offline end and not the operational end, because MonitorStatus is a
  * ladder rather than a pair: the seeded rows run Operational (1) ...
@@ -74,6 +86,24 @@ export interface DeviceHealthStateInput {
   lastPolledAt?: Date | string | null | undefined;
   lastSeenAt?: Date | string | null | undefined;
   pollingIntervalInMinutes?: number | null | undefined;
+  /*
+   * How this device's health is established. NULL, empty and anything
+   * unrecognised read as Probe — see NetworkDeviceMonitoringMethodUtil.parse,
+   * which is why an omitted value keeps every existing caller on the poll
+   * rule unchanged.
+   *
+   * Load-bearing twice. It decides whether `monitorStatusIsOffline` above is
+   * read at all (only for a monitor-backed device). And when a monitor-backed
+   * device has NO stamped status to read — nothing bound yet, or bound and
+   * never evaluated — the shared rule answers Pending ("unknown" here)
+   * rather than falling through to the poll columns, which on such a device
+   * are either NULL or, worse, the last thing a probe found before it
+   * stopped asking: a device switched from Probe to Monitor keeps its old
+   * lastSeenAt until the switch-over clears it, and a caller that dropped
+   * this field would let that months-old timestamp call the device "down" on
+   * the site card while its own row in the device list reads Pending.
+   */
+  monitoringMethod?: string | null | undefined;
   interfacesDown?: number | null | undefined;
 }
 
@@ -96,11 +126,13 @@ export interface DeviceHealthCounts {
 /**
  * The state of one device.
  *
- * Order is load-bearing. A stamped monitor status is the operator's own
- * system of record and beats everything; then hard-down beats everything
- * else, because a device that does not answer has interface counts that
- * are by definition stale; then — and only for a device known to be up —
- * dark ports make it degraded.
+ * Order is load-bearing. On a monitor-backed device the stamped monitor
+ * status is the operator's own system of record and beats everything; on a
+ * probe-polled one the poll's outcome does (the stamp is informational —
+ * see the input docs); then hard-down beats everything else, because a
+ * device that does not answer has interface counts that are by definition
+ * stale; then — and only for a device known to be up — dark ports make it
+ * degraded.
  *
  * Note what this means for a device stamped "Degraded": the ladder does not
  * call it offline, so it is up, and it lands in "degraded" only if it also
@@ -119,9 +151,19 @@ export function deviceHealthState(
 
   let isUp: boolean;
 
+  /*
+   * The stamp is read for a monitor-backed device and nothing else. The
+   * shared reachability rule below applies the same gate, so the two
+   * branches cannot be reached with different ideas of what kind of device
+   * this is.
+   */
+  const isMonitorBacked: boolean =
+    NetworkDeviceMonitoringMethodUtil.isMonitorBacked(device.monitoringMethod);
+
   if (
-    device.monitorStatusIsOffline === true ||
-    device.monitorStatusIsOffline === false
+    isMonitorBacked &&
+    (device.monitorStatusIsOffline === true ||
+      device.monitorStatusIsOffline === false)
   ) {
     // Anything the ladder does not call OFFLINE is up. See the input docs.
     isUp = !device.monitorStatusIsOffline;
@@ -133,6 +175,15 @@ export function deviceHealthState(
           lastPolledAt: device.lastPolledAt,
           lastSeenAt: device.lastSeenAt,
           pollingIntervalInMinutes: device.pollingIntervalInMinutes,
+          /*
+           * Carried so the shared rule knows whether the poll columns above
+           * mean anything. A monitor-backed device only reaches this branch
+           * with NO stamped status (the one above took every stamped one),
+           * so for it this is exactly the "Pending" case — see the input
+           * docs. A probe-polled device always reaches it, stamp or no
+           * stamp, and is judged by its poll.
+           */
+          monitoringMethod: device.monitoringMethod,
         },
         now,
       );

package/Utils/NetworkDevice/DeviceReachabilityUtil.ts

@@ -1,5 +1,6 @@
 import OneUptimeDate from "../../Types/Date";
 import { NetworkDeviceMonitoringMethodUtil } from "../../Types/NetworkDevice/NetworkDeviceMonitoringMethod";
+import ObjectID from "../../Types/ObjectID";
 
 /*
  * The one place that decides whether a NetworkDevice is reachable.
@@ -21,13 +22,15 @@ import { NetworkDeviceMonitoringMethodUtil } from "../../Types/NetworkDevice/Net
  * window.
  *
  * So reachability is now the OUTCOME of the most recent poll —
- * NetworkDevice.isReachable, stamped by the walk pipeline on every ingested
- * walk — and freshness is only a backstop for "the polling pipeline itself
- * stopped", measured generously against the device's own interval.
+ * NetworkDevice.isReachable, stamped by the poll pipeline on every ingested
+ * poll (a ping, plus the SNMP walk on a device that has credentials; the
+ * device is reachable when either answers) — and freshness is only a
+ * backstop for "the polling pipeline itself stopped", measured generously
+ * against the device's own interval.
  *
  * All of which is about a device that gets POLLED. A monitor-backed device
- * (monitoringMethod "Monitor") is never polled at all: no probe, no
- * credentials, no walk. Every poll column on such a row is NULL forever, so
+ * (monitoringMethod "Monitor") is never polled at all: no probe, no ping,
+ * no walk. Every poll column on such a row is NULL forever, so
  * the rule above can only ever answer "Pending" for it — which is
  * OneUptime/oneuptime#3392, a correctly bound ping-only device stuck on
  * Pending. Its health comes from the Monitor bound to it, stamped onto
@@ -69,12 +72,13 @@ export const DEVICE_MIN_STALE_WINDOW_IN_MINUTES: number = 60;
 // The columns this util reads. Every caller selects exactly these.
 export interface DeviceReachabilityInput {
   /*
-   * Outcome of the most recent poll: true = the device answered, false = the
-   * probe could not reach it, null/undefined = never polled, or a row
-   * written before this column existed.
+   * Outcome of the most recent poll: true = the device answered (ping, or
+   * the SNMP walk — either is enough), false = the probe could not reach it
+   * by any means, null/undefined = never polled, or a row written before
+   * this column existed.
    */
   isReachable?: boolean | null | undefined;
-  // When the probe last ATTEMPTED a walk, whatever the outcome.
+  // When the probe last ATTEMPTED a poll, whatever the outcome.
   lastPolledAt?: Date | string | null | undefined;
   // When the device last ANSWERED one.
   lastSeenAt?: Date | string | null | undefined;
@@ -82,7 +86,7 @@ export interface DeviceReachabilityInput {
   pollingIntervalInMinutes?: number | null | undefined;
   /*
    * How this device's health is established. NULL, empty and anything
-   * unrecognised read as SNMP — see NetworkDeviceMonitoringMethodUtil.parse,
+   * unrecognised read as Probe — see NetworkDeviceMonitoringMethodUtil.parse,
    * which is why an omitted value keeps every existing caller on the poll
    * rule unchanged.
    */
@@ -102,6 +106,31 @@ export interface DeviceReachabilityInput {
    * way for the same reason.
    */
   monitorStatusIsOffline?: boolean | null | undefined;
+
+  /*
+   * QUALIFIER inputs. None of the four below moves the Up / Down / Pending
+   * verdict — the rule above is deliberately decided by `isReachable` alone,
+   * so the pill, the summary tiles and the Status chip (all SQL over that one
+   * column) can never disagree. They ride on the same input so a surface can
+   * hand its whole row over once and put the second, explanatory pill
+   * ("SNMP failing", "No probe") beside the verdict; see the predicates in
+   * the dashboard's DeviceStatusUtil.
+   *
+   * `isSnmpReachable`: the outcome of the last SNMP WALK, separate from the
+   * ping — false is a device that answers ping but not SNMP (credentials, or
+   * SNMP disabled on the box), NULL is "no walk was attempted": no usable
+   * credentials, or never polled.
+   */
+  isSnmpReachable?: boolean | null | undefined;
+  // When the last SUCCESSFUL walk completed; only moves on a success.
+  lastSnmpSeenAt?: Date | string | null | undefined;
+  /*
+   * Which probe polls the device, and whether it is allowed to. A probe-polled
+   * device with no probe, or with polling switched off, can never be polled
+   * and is Pending for as long as that stays true.
+   */
+  probeId?: ObjectID | string | null | undefined;
+  isPollingEnabled?: boolean | null | undefined;
 }
 
 export interface DeviceReachabilityResult {
@@ -119,10 +148,10 @@ export interface DeviceReachabilityResult {
   // Latest of lastPolledAt / lastSeenAt; null when neither is set.
   lastContactAt: Date | null;
   /*
-   * True when this verdict came from the bound Monitor rather than from an
-   * SNMP poll. Carried so a surface can word its pill and its tooltip for
-   * what actually decided the answer — "the last SNMP poll reached this
-   * device" is a lie on a device nothing polls.
+   * True when this verdict came from the bound Monitor rather than from a
+   * probe's poll. Carried so a surface can word its pill and its tooltip for
+   * what actually decided the answer — "the last poll reached this device"
+   * is a lie on a device nothing polls.
    */
   isMonitorBacked: boolean;
 }

package/Utils/NetworkDevice/NetworkAlertPolicyBootstrapUtil.ts

@@ -0,0 +1,247 @@
+import MonitorTemplate from "../../Models/DatabaseModels/MonitorTemplate";
+import NetworkAlertPolicy from "../../Models/DatabaseModels/NetworkAlertPolicy";
+import { CriteriaAlert } from "../../Types/Monitor/CriteriaAlert";
+import { CriteriaIncident } from "../../Types/Monitor/CriteriaIncident";
+import MonitorCriteria from "../../Types/Monitor/MonitorCriteria";
+import MonitorCriteriaInstance from "../../Types/Monitor/MonitorCriteriaInstance";
+import MonitorStep from "../../Types/Monitor/MonitorStep";
+import { MonitorStepNetworkDeviceMonitorUtil } from "../../Types/Monitor/MonitorStepNetworkDeviceMonitor";
+import MonitorSteps from "../../Types/Monitor/MonitorSteps";
+import MonitorType from "../../Types/Monitor/MonitorType";
+import NetworkDeviceAlertPackUtil from "../../Types/Monitor/SnmpMonitor/NetworkDeviceAlertPack";
+import { NetworkAlertPolicyScopeUtil } from "../../Types/NetworkDevice/NetworkAlertPolicyScope";
+import ObjectID from "../../Types/ObjectID";
+
+/*
+ * The "one click to alerting" path for network devices.
+ *
+ * An alert policy is only useful once it has a Network Device monitor
+ * template to clone, and building one by hand means walking the monitor
+ * template form: pick the type, add a step, add five criteria, fill in a
+ * severity and a status on each. Most operators want exactly the Recommended
+ * Alert Pack (NetworkDeviceAlertPack) on every device, so this util builds
+ * that template and the policy that applies it to the whole project, and the
+ * settings page find-or-creates the pair from its empty state.
+ *
+ * FIND-OR-CREATE BY MARKER. The template carries RECOMMENDED_TEMPLATE_MARKER
+ * in its description. The name is what an operator renames; the marker is
+ * what the bootstrap looks for, so clicking "create the recommended policy"
+ * twice — or after the recommended policy was deleted and its template kept
+ * — reuses the template instead of minting a second one, and instead of
+ * tripping the policy service's "another policy already uses this template"
+ * refusal on a duplicate nobody meant to make.
+ *
+ * WHY THE ITEMS ARE FILLED IN HERE. NetworkDeviceAlertPackUtil deliberately
+ * leaves severities and on-call policies for the user to complete on the
+ * monitor form. A policy's monitors are never opened in that form — the
+ * engine clones them — so a criteria whose `createIncidents` is on but whose
+ * `incidents` list is empty would clone into monitors that fire nothing.
+ * Every incident-creating item therefore gets one CriteriaIncident and every
+ * alert-creating item one CriteriaAlert, both auto-resolving, at the
+ * project's lowest-order severity (PingMonitorSeedIds resolves that).
+ *
+ * NO DEVICE ON THE TEMPLATE STEP. A Network Device step names the device it
+ * watches; a template step is a placeholder the engine rebinds per device
+ * (NetworkDeviceMonitorTemplateUtil.rebindMonitorSteps), which requires the
+ * `networkDeviceMonitor` block to exist and ignores what id it holds. The
+ * step is built with the block present and the id unset, which the
+ * template's reference validator skips rather than rejects.
+ *
+ * Pure: no database, no permissions. The caller persists both rows through
+ * ModelAPI / the services so tenancy, billing and the policy engine's hooks
+ * all run.
+ */
+
+export const RECOMMENDED_TEMPLATE_MARKER: string =
+  "[oneuptime:network-alert-pack:v1]";
+
+export const RECOMMENDED_TEMPLATE_NAME: string =
+  "Network device alert pack (recommended)";
+
+export const RECOMMENDED_POLICY_NAME: string = "Alert on every device";
+
+export interface RecommendedMonitorTemplateSeedIds {
+  projectId: ObjectID;
+  incidentSeverityId: ObjectID;
+  alertSeverityId: ObjectID;
+  onlineMonitorStatusId: ObjectID;
+  offlineMonitorStatusId: ObjectID;
+}
+
+export interface RecommendedPolicySeedIds {
+  projectId: ObjectID;
+  monitorTemplateId: ObjectID;
+}
+
+/*
+ * The slice of a MonitorTemplate the marker check reads. Kept to one
+ * optional field so a caller that listed templates with a narrow `select`
+ * can still ask.
+ */
+export interface RecommendedTemplateCandidate {
+  templateDescription?: string | undefined;
+}
+
+export default class NetworkAlertPolicyBootstrapUtil {
+  /**
+   * The template every device's monitor is cloned from: a Network Device
+   * template whose single step carries the Recommended Alert Pack, with an
+   * incident or an alert filled in on every item.
+   */
+  public static buildRecommendedMonitorTemplate(
+    data: RecommendedMonitorTemplateSeedIds,
+  ): MonitorTemplate {
+    const criteriaInstances: Array<MonitorCriteriaInstance> =
+      NetworkDeviceAlertPackUtil.buildCriteriaInstances({
+        downMonitorStatusId: data.offlineMonitorStatusId,
+      });
+
+    for (const criteriaInstance of criteriaInstances) {
+      NetworkAlertPolicyBootstrapUtil.fillCriteriaActions({
+        criteriaInstance: criteriaInstance,
+        incidentSeverityId: data.incidentSeverityId,
+        alertSeverityId: data.alertSeverityId,
+      });
+    }
+
+    const monitorCriteria: MonitorCriteria = new MonitorCriteria();
+    monitorCriteria.data = {
+      monitorCriteriaInstanceArray: criteriaInstances,
+    };
+
+    const monitorStep: MonitorStep = new MonitorStep();
+    monitorStep.data!.networkDeviceMonitor =
+      MonitorStepNetworkDeviceMonitorUtil.getDefault();
+    monitorStep.data!.monitorCriteria = monitorCriteria;
+
+    const monitorSteps: MonitorSteps = new MonitorSteps();
+    monitorSteps.data = {
+      monitorStepsInstanceArray: [monitorStep],
+      /*
+       * Where the monitor goes when no pack item matches — the device is
+       * reachable, its walk succeeds, its interfaces are up. Without this a
+       * monitor that once went Offline would never come back.
+       */
+      defaultMonitorStatusId: new ObjectID(
+        data.onlineMonitorStatusId.toString(),
+      ),
+    };
+
+    const template: MonitorTemplate = new MonitorTemplate();
+    template.projectId = new ObjectID(data.projectId.toString());
+    template.templateName = RECOMMENDED_TEMPLATE_NAME;
+    template.templateDescription =
+      NetworkAlertPolicyBootstrapUtil.buildRecommendedTemplateDescription();
+    template.monitorType = MonitorType.NetworkDevice;
+    template.monitorSteps = monitorSteps;
+    /*
+     * Left blank on purpose: a policy's monitors are named after the device
+     * alone, and a default monitor name would become a suffix on every one
+     * of them (the auto-import precedent, issue #3486).
+     */
+    template.monitorDescription =
+      "Provisioned by a Network Alert Policy. Edit the policy's template to change what this monitor alerts on; it is re-synced from the template, so edits made here are overwritten.";
+
+    return template;
+  }
+
+  /**
+   * The policy that applies the template to every device in the project.
+   * Unscoped on purpose — that is what "recommended" means here, and the
+   * settings table says "All devices" against it so nobody misreads the
+   * reach.
+   */
+  public static buildRecommendedPolicy(
+    data: RecommendedPolicySeedIds,
+  ): NetworkAlertPolicy {
+    const policy: NetworkAlertPolicy = new NetworkAlertPolicy();
+    policy.projectId = new ObjectID(data.projectId.toString());
+    policy.name = RECOMMENDED_POLICY_NAME;
+    policy.description =
+      "Every probe-polled device in the project gets a Network Device monitor cloned from the recommended alert pack: an incident when it stops answering ping and SNMP or an interface goes down, and an alert when its SNMP walk fails, an interface saturates or an interface logs errors. A device with no SNMP credentials is pinged rather than walked, so only the reachability item can fire on it until credentials are set. Narrow the scope to sites, roles or labels to cover fewer devices.";
+    policy.isEnabled = true;
+    policy.monitorTemplateId = new ObjectID(data.monitorTemplateId.toString());
+    policy.scope = NetworkAlertPolicyScopeUtil.normalize({});
+
+    return policy;
+  }
+
+  /** Whether a template is the one this util minted, by its marker. */
+  public static isRecommendedTemplate(
+    template: RecommendedTemplateCandidate | null | undefined,
+  ): boolean {
+    return (template?.templateDescription || "").includes(
+      RECOMMENDED_TEMPLATE_MARKER,
+    );
+  }
+
+  /**
+   * The recommended template among a project's templates, or null. The
+   * first marked one wins so a project that somehow holds two keeps reusing
+   * the same one rather than alternating.
+   */
+  public static findRecommendedTemplate<
+    TTemplate extends RecommendedTemplateCandidate,
+  >(templates: Array<TTemplate>): TTemplate | null {
+    for (const template of templates) {
+      if (NetworkAlertPolicyBootstrapUtil.isRecommendedTemplate(template)) {
+        return template;
+      }
+    }
+
+    return null;
+  }
+
+  /**
+   * The description the marker lives in. The marker is on its own line at
+   * the end so an operator can rewrite the prose above it without losing
+   * the tag that makes the template findable.
+   */
+  public static buildRecommendedTemplateDescription(): string {
+    return `The Recommended Alert Pack for network devices: an incident when a device stops answering ping and SNMP or an interface goes down, an alert when the SNMP walk fails, an interface runs above 80% utilization or an interface logs errors. Created by the "Create the recommended policy" action under Network > Settings > Alert Policies; edit the criteria here and every monitor the policy provisions follows. Keep the marker below so the action can find this template again.\n\n${RECOMMENDED_TEMPLATE_MARKER}`;
+  }
+
+  /*
+   * One CriteriaIncident on an incident-creating item, one CriteriaAlert on
+   * an alert-creating one, titled after the pack item so the incident an
+   * operator is paged with reads "Device unreachable", not "Criteria 1".
+   */
+  private static fillCriteriaActions(data: {
+    criteriaInstance: MonitorCriteriaInstance;
+    incidentSeverityId: ObjectID;
+    alertSeverityId: ObjectID;
+  }): void {
+    const criteriaData: MonitorCriteriaInstance["data"] =
+      data.criteriaInstance.data;
+
+    if (!criteriaData) {
+      return;
+    }
+
+    if (criteriaData.createIncidents) {
+      const incident: CriteriaIncident = {
+        id: ObjectID.generate().toString(),
+        title: criteriaData.name,
+        description: criteriaData.description,
+        incidentSeverityId: new ObjectID(data.incidentSeverityId.toString()),
+        autoResolveIncident: true,
+        onCallPolicyIds: [],
+      };
+
+      criteriaData.incidents = [incident];
+    }
+
+    if (criteriaData.createAlerts) {
+      const alert: CriteriaAlert = {
+        id: ObjectID.generate().toString(),
+        title: criteriaData.name,
+        description: criteriaData.description,
+        alertSeverityId: new ObjectID(data.alertSeverityId.toString()),
+        autoResolveAlert: true,
+        onCallPolicyIds: [],
+      };
+
+      criteriaData.alerts = [alert];
+    }
+  }
+}

package/Utils/NetworkDevice/SnmpCredentialUtil.ts

@@ -0,0 +1,68 @@
+import { SnmpVersionUtil } from "../../Types/Monitor/SnmpMonitor/SnmpVersion";
+
+/*
+ * "Does this row carry enough to open an SNMP session with?"
+ *
+ * The question is asked of three different rows in turn at poll time - the
+ * device's own snmp* columns, the profile the device points at, and the
+ * profile the device's site points at - and the first row that answers yes is
+ * the one the device is walked with. A device with no usable set anywhere is
+ * pinged and never walked. So this function is the resolution order's
+ * predicate, and it is deliberately shaped to accept ANY object carrying the
+ * three fields it reads rather than a NetworkDevice or a
+ * NetworkSnmpCredentialProfile specifically: the caller hands it whichever
+ * row it is looking at and gets the same answer for each.
+ *
+ * "Usable" is the minimum an SNMP session needs to be attempted, not a
+ * guarantee it will succeed:
+ *
+ *   - v1 / v2c: a non-empty community string. There is nothing else to send.
+ *   - v3: a non-empty security name (username). Auth and privacy keys are
+ *     legitimately absent at noAuthNoPriv, so their absence must not make a
+ *     v3 row unusable; a wrong key at a higher level is the device's error to
+ *     report, not this function's to predict.
+ *
+ * Whitespace-only values count as empty. A community string of "   " is what
+ * a form submits when an operator clears the field without the browser
+ * sending null, and it is not a credential anything will accept.
+ *
+ * The version is read through SnmpVersionUtil.parse, never compared as raw
+ * text, for the reason that module documents: the stored spelling is "V3"
+ * and the enum's is "3", and a raw comparison sends a v3 row down the v2c
+ * branch. parse() treats a missing or unrecognised version as v2c, which is
+ * also the column default on both the device and the profile - so a row with
+ * a community string and no version at all is usable, exactly as it would be
+ * polled.
+ */
+
+/*
+ * `| undefined` is spelled out on each field because the repo compiles with
+ * exactOptionalPropertyTypes: a caller building the carrier from a row it
+ * only partially selected (`{ snmpVersion: row.snmpVersion }`) hands over an
+ * explicit undefined, and that must type-check as readily as an omitted key.
+ */
+export interface SnmpCredentialCarrier {
+  snmpVersion?: string | null | undefined;
+  snmpCommunityString?: string | null | undefined;
+  snmpV3Username?: string | null | undefined;
+}
+
+export type HasUsableCredentialsFunction = (
+  carrier: SnmpCredentialCarrier,
+) => boolean;
+
+function isNonEmpty(value: string | null | undefined): boolean {
+  return typeof value === "string" && value.trim().length > 0;
+}
+
+export const hasUsableCredentials: HasUsableCredentialsFunction = (
+  carrier: SnmpCredentialCarrier,
+): boolean => {
+  if (SnmpVersionUtil.isV3(carrier.snmpVersion)) {
+    return isNonEmpty(carrier.snmpV3Username);
+  }
+
+  return isNonEmpty(carrier.snmpCommunityString);
+};
+
+export default hasUsableCredentials;

package/Utils/NetworkDiscovery/AutoImportRuleMatcher.ts

@@ -1,9 +1,8 @@
 import { DiscoveredNetworkDevice } from "../../Models/DatabaseModels/NetworkDeviceDiscoveryScan";
-import NetworkDeviceMonitoringMethod from "../../Types/NetworkDevice/NetworkDeviceMonitoringMethod";
 import ObjectID from "../../Types/ObjectID";
 import CidrMatchUtil from "../NetworkSite/CidrMatchUtil";
 import RulePatternMatchUtil from "../Rules/RulePatternMatchUtil";
-import { monitoringMethodForDiscoveredHost } from "./DiscoveryImportEligibility";
+import { isPingOnlyDiscoveredHost } from "./DiscoveryImportEligibility";
 import ScanTargetUtil from "./ScanTargetUtil";
 
 /*
@@ -134,12 +133,21 @@ export function matchesOidPattern(
 }
 
 export class AutoImportRuleMatcher {
-  // True when the host answered ping but not SNMP.
+  /*
+   * True when the host answered ping but not SNMP.
+   *
+   * Asked of the host's own SNMP answer (`isPingOnlyDiscoveredHost`), NOT of
+   * the method it would import under. Under ping-first polling EVERY
+   * discovered host imports as a Probe device, so
+   * `monitoringMethodForDiscoveredHost` is a constant — routing this gate
+   * through it made `isPingOnlyHost` permanently false and silently opened
+   * the default-closed gate below: one SNMP credential typo would have
+   * imported a whole subnet of half-identified hosts through rules that never
+   * opted in. How a host is MONITORED and what it ANSWERED are two different
+   * questions now, and this one is the second.
+   */
   private static isPingOnlyHost(host: DiscoveredNetworkDevice): boolean {
-    return (
-      monitoringMethodForDiscoveredHost(host) ===
-      NetworkDeviceMonitoringMethod.Monitor
-    );
+    return isPingOnlyDiscoveredHost(host);
   }
 
   /*