wf work

docs/BACKUPS.md

@@ -4,20 +4,21 @@
 > To backup 99% of your configuration backup at least the `/app/config` folder. Please read the whole page (or at least "Scenario 2: Corrupted database") for details.
 > Note that database definitions might change over time. The safest way is to restore your older backups into the **same version** of the app they were taken from and then gradually upgarde between releases to the latest version.
 
-There are 3 artifacts that can be used to backup the application:
+There are 4 artifacts that can be used to backup the application:
 
 | File                  | Description                   | Limitations                   |
 |-----------------------|-------------------------------|-------------------------------|
 | `/db/app.db`       | Database file(s)  | The database file might be in an uncommitted state or corrupted |
 | `/config/app.conf` | Configuration file |  Can be overridden with the [`APP_CONF_OVERRIDE` env variable](https://github.com/jokob-sk/NetAlertX/tree/main/dockerfiles#docker-environment-variables).  |
 | `/config/devices.csv`  | CSV file containing device information |     Doesn't contain historical data        |
+| `/config/workflows.json`  | A JSON file containing your workflows |     N/A        |
 
 
 ## Backup strategies
 
-The safest approach to backups is to backup everything, by taking regular file system backups (I use [Kopia](https://github.com/kopia/kopia)). 
+The safest approach to backups is to backup everything, by taking regular file system backups of the `/db` and `/config` folders (I use [Kopia](https://github.com/kopia/kopia)). 
 
-Arguably, the most time is spent setting up the device list, so if only one file is kept I'd recommend to have a latest backup of the `devices_<timestamp>.csv` or `devices.csv` file, followed by the `app.conf` file. You can also download `app.conf` and `devices.csv` file in the Maintenance section:
+Arguably, the most time is spent setting up the device list, so if only one file is kept I'd recommend to have a latest backup of the `devices_<timestamp>.csv` or `devices.csv` file, followed by the `app.conf` and `workflows.json` files. You can also download `app.conf` and `devices.csv` file in the Maintenance section:
 
 ![Backup and Restore Section in Maintenance](./img/BACKUPS/Maintenance_Backup_Restore.png)
 
@@ -29,6 +30,7 @@ End-result: Full restore
 
 - `/app/db/app.db` (uncorrupted)
 - `/app/config/app.conf`
+- `/app/config/workflows.json`
 
 #### 📥 Recovery:
 
@@ -43,12 +45,13 @@ End-result: Partial restore (historical data and some plugin data will be missin
 
 - `/app/config/app.conf`
 - `/app/config/devices_<timestamp>.csv` or `/app/config/devices.csv`
+- `/app/config/workflows.json`
 
 #### 📥 Recovery:
 
 Even with a corrupted database you can recover what I would argue is 99% of the configuration. 
 
-- upload the `app.conf` file into the mounted `/app/config/` folder as described in the [Setup documentation](https://github.com/jokob-sk/NetAlertX/blob/main/dockerfiles/README.md#docker-paths).
+- upload the `app.conf` and `workflows.json` files into the mounted `/app/config/` folder as described in the [Setup documentation](https://github.com/jokob-sk/NetAlertX/blob/main/dockerfiles/README.md#docker-paths).
 - rename the `devices_<timestamp>.csv` to `devices.csv` and place it in the `/app/config` folder
 - Restore the `devices.csv` backup via the [Maintenance section](./DEVICES_BULK_EDITING.md)
 

docs/NOTIFICATIONS.md

@@ -17,8 +17,8 @@ There are 4 ways how to influence notifications:
 
 There are 4 settings on the device for influencing notifications. You can:
 
-1. **Alert Events** - Enables alerts of connections, disconnections, IP changes.
-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.
+1. **Alert Events** - Enables alerts of connections, disconnections, IP changes (down and down reconnected notifications are still sent even if this is disabled).
+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.
 
 ## Plugin settings 🔌
@@ -38,7 +38,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)
+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. 
 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

@@ -56,7 +56,7 @@ Below you can find a couple of configuration examples.
 
 ### Trigger:
 - **Object Type**: `Devices`
-- **Event Type**: `insert`
+- **Event Type**: `create`
 
 ### Conditions:
 - **Logic**: `AND`