mirror of
https://github.com/jokob-sk/NetAlertX.git
synced 2025-12-07 09:36:05 -08:00
FE: regex validation for cron run schedules
Signed-off-by: jokob-sk <jokob.sk@gmail.com>
This commit is contained in:
jokob-sk
@@ -1,62 +1,64 @@
|
||||
# Sessions Section in Device View
|
||||
# Sessions Section – Device View
|
||||
|
||||
The **Sessions Section** provides details about a device's connection history. This data is automatically detected and cannot be edited by the user.
|
||||
The **Sessions Section** shows a device’s connection history. All data is automatically detected and **cannot be edited**.
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Key Fields
|
||||
|
||||
1. **Date and Time of First Connection**
|
||||
- **Description:** Displays the first detected connection time for the device.
|
||||
- **Editability:** Uneditable (auto-detected).
|
||||
- **Source:** Automatically captured when the device is first added to the system.
|
||||
|
||||
2. **Date and Time of Last Connection**
|
||||
- **Description:** Shows the most recent time the device was online.
|
||||
- **Editability:** Uneditable (auto-detected).
|
||||
- **Source:** Updated with every new connection event.
|
||||
|
||||
3. **Offline Devices with Missing or Conflicting Data**
|
||||
- **Description:** Handles cases where a device is offline but has incomplete or conflicting session data (e.g., missing start times).
|
||||
- **Handling:** The system flags these cases for review and attempts to infer missing details.
|
||||
| Field | Description | Editable? |
|
||||
| ------------------------------ | ------------------------------------------------------------------------------------------------ | --------------- |
|
||||
| **First Connection** | The first time the device was detected on the network. | ❌ Auto-detected |
|
||||
| **Last Connection** | The most recent time the device was online. | ❌ Auto-detected |
|
||||
|
||||
---
|
||||
|
||||
## How Sessions are Discovered and Calculated
|
||||
## How Session Information Works
|
||||
|
||||
### 1. Detecting New Devices
|
||||
When a device is first detected in the network, the system logs it in the events table:
|
||||
|
||||
`INSERT INTO Events (eve_MAC, eve_IP, eve_DateTime, eve_EventType, eve_AdditionalInfo, eve_PendingAlertEmail) SELECT cur_MAC, cur_IP, '{startTime}', 'New Device', cur_Vendor, 1 FROM CurrentScan WHERE NOT EXISTS (SELECT 1 FROM Devices WHERE devMac = cur_MAC)`
|
||||
* New devices are automatically detected when they first appear on the network.
|
||||
* A **New Device** record is created, capturing the MAC, IP, vendor, and detection time.
|
||||
|
||||
- Devices scanned in the current cycle (**CurrentScan**) are checked against the **Devices** table.
|
||||
- If a device is new:
|
||||
- A **New Device** event is logged.
|
||||
- The device’s MAC, IP, vendor, and detection time are recorded.
|
||||
### 2. Recording Connection Sessions
|
||||
|
||||
### 2. Logging Connection Sessions
|
||||
When a new connection is detected, the system creates a session record:
|
||||
* Every time a device connects, a session entry is created.
|
||||
* Captured details include:
|
||||
|
||||
`INSERT INTO Sessions (ses_MAC, ses_IP, ses_EventTypeConnection, ses_DateTimeConnection, ses_EventTypeDisconnection, ses_DateTimeDisconnection, ses_StillConnected, ses_AdditionalInfo) SELECT cur_MAC, cur_IP, 'Connected', '{startTime}', NULL, NULL, 1, cur_Vendor FROM CurrentScan WHERE NOT EXISTS (SELECT 1 FROM Sessions WHERE ses_MAC = cur_MAC)`
|
||||
|
||||
- A new session is logged in the **Sessions** table if no prior session exists.
|
||||
- Fields like `MAC`, `IP`, `Connection Type`, and `Connection Time` are populated.
|
||||
- The `Still Connected` flag is set to `1` (active connection).
|
||||
* Connection type (wired or wireless)
|
||||
* Connection time
|
||||
* Device details (MAC, IP, vendor)
|
||||
|
||||
### 3. Handling Missing or Conflicting Data
|
||||
- Devices with incomplete or conflicting session data (e.g., missing start times) are detected.
|
||||
- The system flags these records and attempts corrections by inferring details from available data.
|
||||
|
||||
* **Triggers:**
|
||||
Devices are flagged when session data is incomplete, inconsistent, or conflicting. Examples include:
|
||||
|
||||
* Missing first or last connection timestamps
|
||||
* Overlapping session records
|
||||
* Sessions showing a device as connected and disconnected at the same time
|
||||
|
||||
* **System response:**
|
||||
|
||||
* Automatically highlights affected devices in the **Sessions Section**.
|
||||
* Attempts to **infer missing information** from available data, such as:
|
||||
|
||||
* Estimating first or last connection times from nearby session events
|
||||
* Correcting overlapping session periods
|
||||
* Reconciling conflicting connection statuses
|
||||
|
||||
* **User impact:**
|
||||
|
||||
* Users do **not** need to manually fix session data.
|
||||
* The system ensures the device’s connection history remains as accurate as possible for monitoring and reporting.
|
||||
|
||||
### 4. Updating Sessions
|
||||
- When a device reconnects, its session is updated with a new connection timestamp.
|
||||
- When a device disconnects:
|
||||
- The **Disconnection Time** is recorded.
|
||||
- The `Still Connected` flag is set to `0`.
|
||||
|
||||
The session information is then used to display the device presence under **Monitoring** -> **Presence**.
|
||||
* **Reconnect:** Updates session with the new connection timestamp.
|
||||
* **Disconnect:** Records disconnection time and marks the device as offline.
|
||||
|
||||
This session information feeds directly into **Monitoring → Presence**, providing a live view of which devices are currently online.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user