Merge pull request #1675 from netalertx/next_release

Next release

Author: jokob-sk

.gemini/skills/initiative-start/reasearch-skill.md

@@ -0,0 +1,131 @@
+### 🧠 NAX Research Skill — Specification
+
+This defines a **Research Skill module for NAX (NetAlertX)** focused on safe, structured analysis before any implementation work.
+
+---
+
+## 1. Purpose
+
+Ensure all work begins with **documentation-first understanding**, **PRD validation**, and **conflict detection**, before any planning or coding.
+
+---
+
+## 2. Core Workflow
+
+### Step 1 — Documentation First
+
+* Always begin by reading relevant repository documentation.
+
+* Priority order:
+
+  1. `/CONTRIBUTING.md`
+  2. `/README.md`
+  3. `/.github/skills/code-standards/SKILL.md`
+  4. `/docs/**`
+  5. Related module/code context if referenced
+
+* Extract:
+
+  * Architecture expectations
+  * Coding standards
+  * Plugin or module conventions
+  * Existing workflows or constraints
+
+---
+
+### Step 2 — PRD Check
+
+* If a PRD (Product Requirements Document) is NOT provided:
+
+  * Explicitly request it before proceeding further
+  * Do not assume requirements
+
+* If PRD is provided:
+
+  * Parse and restate key requirements internally
+  * Identify scope boundaries
+
+---
+
+### Step 3 — Clarification Gate
+
+If anything is unclear:
+
+* Stop immediately
+* Ask targeted clarifying questions
+* Do NOT propose solutions yet
+
+---
+
+### Step 4 — Codebase Cross-Check
+
+* Compare PRD + documentation against existing codebase
+
+* Identify:
+
+  * Conflicting behavior
+  * Outdated patterns
+  * Duplicate logic
+  * Breaking assumptions
+  * Plugin or API mismatches
+
+* Clearly report inconsistencies before proceeding
+
+---
+
+### Step 5 — Planning Requirement (Strict)
+
+Before any implementation:
+
+* Produce a structured plan including:
+
+  * Approach overview
+  * Files/modules affected
+  * Dependencies
+  * Risk areas
+  * Migration considerations (if any)
+
+* Explicitly label:
+
+  > “WAITING FOR USER CONFIRMATION”
+
+---
+
+### Step 6 — Implementation Gate (Hard Rule)
+
+* Do NOT start implementation until user explicitly confirms the plan
+* No partial coding, no early patches, no assumptions
+
+---
+
+## 3. Behavioral Constraints
+
+* Always prioritize correctness over speed
+* Never skip PRD validation
+* Never proceed past ambiguity
+* Never implement without approval
+* Always surface contradictions in source material
+* Always prefer asking questions over guessing
+
+---
+
+## 4. Output Style Rules
+
+* Be structured and technical
+* Avoid unnecessary verbosity
+* Separate:
+
+  * Findings
+  * Risks
+  * Questions
+  * Plan
+* No hidden assumptions
+
+---
+
+## 5. Summary Flow
+
+```
+Docs → PRD → Clarify → Codebase Check → Plan → User Approval → Implement
+```
+

.gitignore

@@ -19,6 +19,7 @@ db/pialert.db
 db/app.db
 front/log/*
 /log/*
+.gemini/internal-docs/PRDs/*
 /log/plugins/*
 front/api/*
 /api/*

docs/WORKFLOW_EXAMPLES.md

@@ -54,6 +54,7 @@ Sometimes devices are manually archived (e.g., no longer expected on the network
 
   * `devIsArchived` is `1` (archived).
   * `devPresentLastScan` is `1` (device was detected in the latest scan).
+
 * **Action**:
 
   * Updates the device to set `devIsArchived` to `0` (unarchived).
@@ -110,6 +111,7 @@ When new devices join your network, assigning them to the correct network node i
 * **Conditions**:
 
   * `devLastIP` contains `192.168.1.` (matches subnet).
+
 * **Action**:
 
   * Sets `devNetworkNode` to the specified MAC address.
@@ -175,11 +177,78 @@ You may want to automatically clear out newly detected Google devices (such as C
 
   * `devVendor` contains `Google`.
   * `devIsNew` is `1` (device marked as new).
+
 * **Actions**:
 
   1. Sets `devIsNew` to `0` (mark as not new).
   2. Deletes the device.
 
 ### ✅ Result
 
-Any newly detected Google devices are cleaned up instantly — first marked as not new, then deleted — helping you avoid clutter in your device records.
+Any newly detected Google devices are cleaned up instantly — first marked as not new, then deleted — helping you avoid clutter in your device records.
+
+---
+
+## Example 4: On new device discovery archive the old device with the same ip
+
+This workflow automatically archives devices if a new device is discovered with an already assigned IP.
+
+### 📋 Use Case
+
+This workflow is useful if you are assigning static IPs to your devices. This workflow can also help with archiving device entries with [random MAC addresses](./RANDOM_MAC.md). 
+
+### ⚙️ Workflow Configuration
+
+```json
+{
+  "name": "Archive device with same ip",
+  "trigger": {
+    "object_type": "Devices",
+    "event_type": "insert"
+  },
+  "conditions": [
+    {
+      "logic": "AND",
+      "conditions": []
+    }
+  ],
+  "actions": [
+    {
+      "type": "update_field",
+      "field": "devIsArchived",
+      "value": "1",
+      "target": {
+        "strategy": "query",
+        "conditions": [
+          {
+            "field": "devLastIP",
+            "operator": "equals",
+            "value": "{{trigger.devLastIP}}"
+          }
+        ]
+      }
+    }
+  ]
+}
+```
+
+### 🔍 Explanation
+
+* **Trigger**: Runs on a new device being inserted.
+
+* **Conditions**:
+
+  * `N/A`
+
+* **Target Conditions**:
+
+  * `devLastIP` of the target is the same as the newly discovered device's `devLastIP` value.
+
+* **Actions**:
+
+  1. Sets `devIsArchived` to `1` (mark target device as archived).
+
+
+### ✅ Result
+
+Any newly detected device that has the same IP as an existing device will automatically trigger the archival of the old device.

front/css/app.css

@@ -2338,6 +2338,17 @@ textarea[readonly],
     padding: 5px;
 }
 
+.workflows .add-target-condition
+{
+    margin: 10px;
+    text-align: center;
+}
+
+.workflows .inline-hint
+{
+    margin: 5px;
+}
+
 .workflows
 {
     max-width: 800px;
@@ -2430,6 +2441,18 @@ textarea[readonly],
     color: var(--color-green) !important;
 }
 
+.workflows .action-target-conditions
+{
+    opacity: 0.8;
+}
+
+.workflows .bckg-icon-base
+{
+    display: block;
+    position: absolute;
+    opacity: 0.1;
+    right: 0.1em;
+}
 .workflows .bckg-icon-1-line
 {
     font-size: 3em;

front/php/templates/language/en_us.json

@@ -742,6 +742,9 @@
     "VERSION_name": "Version or timestamp",
     "WF_Action_Add": "Add Action",
     "WF_Action_field": "Field",
+    "WF_Action_target": "Apply action to",
+    "WF_Action_target_conditions": "Target device conditions",
+    "WF_Action_token_hint": "Use <code>{{trigger.COLUMN}}</code> to reference the triggering device (e.g. <code>{{trigger.devLastIP}}</code>, <code>{{trigger.devMac}}</code>)",
     "WF_Action_type": "Type",
     "WF_Action_value": "Value",
     "WF_Actions": "Actions",