wf work + docs

docs/DOCKER_COMPOSE.md

@@ -103,3 +103,42 @@ DEV_LOCATION=/path/to/local/source/code
 ```
 
 To run the container execute: `sudo docker-compose --env-file /path/to/.env up`
+
+
+## #Example 4: Docker swarm
+
+Notice how the host network is defined in a swarm setup:
+
+```yaml
+services:
+  netalertx:
+    # Use the below line if you want to test the latest dev image
+    # image: "jokobsk/netalertx-dev:latest"
+    image: "ghcr.io/jokob-sk/netalertx:latest"
+    volumes:
+      - /mnt/MYSERVER/netalertx/config:/config:rw
+      - /mnt/MYSERVER/netalertx/db:/netalertx/db:rw
+      - /mnt/MYSERVER/netalertx/logs:/netalertx/front/log:rw
+    environment:
+      - TZ=Europe/London
+      - PORT=20211
+    # network_mode: host
+    networks:
+      - outside
+    deploy:
+      mode: replicated
+      replicas: 1
+      restart_policy:
+        condition: on-failure
+      # placement: # ✅ Placement is now correctly inside deploy
+      # constraints:
+      #   - node.role == manager
+      #   - node.labels.device == NUC2
+
+networks:
+  outside:
+    external:
+      name: "host"
+
+
+```

docs/NOTIFICATIONS.md

@@ -21,6 +21,9 @@ There are 4 settings on the device for influencing notifications. You can:
 2. **Alert Down** - Alerts when a device goes down. This setting overrides a disabled **Alert Events** setting, so you will get a notification of a device going down even if you don't have **Alert Events** ticked. Disabling this will disable down and down reconnected notifications on the device.
 3. **Skip repeated notifications**, if for example you know there is a temporary issue and want to pause the same notification for this device for a given time.
 
+> [!NOTE]
+> Please read through the [NTFPRCS plugin](https://github.com/jokob-sk/NetAlertX/blob/main/front/plugins/notification_processing/README.md) documentation to understand how device and global settings influence the notification processing. 
+
 ## Plugin settings 🔌
 
 ![Plugin notification settings](./img/NOTIFICATIONS/Plugin-notification-settings.png)
@@ -38,7 +41,7 @@ Click the **Read more in the docs.** Link at the top of each plugin to get more
 
 In Notification Processing settings, you can specify blanket rules. These allow you to specify exceptions to the Plugin and Device settings and will override those.
 
-1. Notify on (`NTFPRCS_INCLUDED_SECTIONS`) allows you to specify which events trigger notifications. Usual setups will have `new_devices`, `down_devices`, and possibly `down_reconnected` set. Including `plugin` (dependenton the Plugin `<plugin>_WATCH` and `<plugin>_REPORT_ON` settings) and `events` (dependent on the on-device **Alert Events** setting) might be too noisy for most setups. More info in the [NTFPRCS plugin](/front/plugins/notification_processing/README.md) on what events these selections include. 
+1. Notify on (`NTFPRCS_INCLUDED_SECTIONS`) allows you to specify which events trigger notifications. Usual setups will have `new_devices`, `down_devices`, and possibly `down_reconnected` set. Including `plugin` (dependenton the Plugin `<plugin>_WATCH` and `<plugin>_REPORT_ON` settings) and `events` (dependent on the on-device **Alert Events** setting) might be too noisy for most setups. More info in the [NTFPRCS plugin](https://github.com/jokob-sk/NetAlertX/blob/main/front/plugins/notification_processing/README.md) on what events these selections include. 
 2. Alert down after (`NTFPRCS_alert_down_time`) is useful if you want to wait for some time before the system sends out a down notification for a device. This is related to the on-device **Alert down** setting and only devices with this checked will trigger a down notification.
 3. A filter to allow you to set device-specific exceptions to New devices being added to the app.
 4. A filter to allow you to set device-specific exceptions to generated Events.

docs/WORKFLOWS.md

@@ -54,9 +54,11 @@ Below you can find a couple of configuration examples.
 
 ## Example 1: Assign Device to Network Node Based on IP
 
+This workflow assigns newly added devices with IP addresses in the `192.168.1.*` range to the device with the MAC address `6c:6d:6d:6c:6c:6c`.
+
 ### Trigger:
 - **Object Type**: `Devices`
-- **Event Type**: `create`
+- **Event Type**: `insert`
 
 ### Conditions:
 - **Logic**: `AND`
@@ -71,12 +73,12 @@ Below you can find a couple of configuration examples.
   - **Field**: `devNetworkNode`
   - **Value**: `6c:6d:6d:6c:6c:6c`
 
-This workflow assigns newly added devices with IP addresses in the `192.168.1.*` range to the device with the MAC address `6c:6d:6d:6c:6c:6c`.
-
 ---
 
 ## Example 2: Mark Device as Not New and Delete If from Google Vendor
 
+This workflow automates the process of marking Google devices as not new and deleting them if they meet the criteria.
+
 ### Trigger:
 - **Object Type**: `Devices`
 - **Event Type**: `update`
@@ -107,7 +109,7 @@ This workflow assigns newly added devices with IP addresses in the `192.168.1.*`
    
    This action deletes the device after it is marked as not new.
 
-This workflow automates the process of marking Google devices as not new and deleting them if they meet the criteria.
+
 
 ---