System Logging & Auditing

Overview of Auditing

Atslegas includes a built-in logging and auditing system designed to track the full lifecycle of physical keys and administrative actions. This ensures accountability by recording who accessed which key, when the action occurred, and the current status of the inventory.

The system distinguishes between two types of logs:

1. Activity Logs: High-level records of key movements (Issuance and Returns) visible to administrators.
2. System Logs: Technical logs generated by the database engine and server for troubleshooting and security monitoring.

Key Lifecycle Tracking

The primary purpose of the auditing system is to monitor the movement of keys. Every time a key's status changes, a log entry is generated with the following metadata:

• Action: The nature of the event (e.g., Izsniegts / Issued or Atgriezti / Returned).
• Timestamp: The exact UTC time of the transaction.
• User/Person: The identifier of the individual responsible for the key.
• Key Identifier: The specific key number or ID involved.
• Comments: Optional notes regarding the state of the key or the reason for the transaction.

Accessing Logs via the Admin Dashboard

Administrators can visualize these logs through the Admin Dashboard using the integrated calendar view:

1. Calendar Strip: Displays a 37-day window (7 days prior to current date, 30 days ahead).
2. Daily Summaries: Each day in the calendar shows a summary of "Izsniegti" (Issued) and "Atgriezti" (Returned) counts.
3. Detailed View: Clicking a specific day populates a detailed list of all actions, showing the time, key number, and associated user.

System & Database Logging

The backend engine provides granular logging for developers and system maintainers to monitor database health and application flow.

Database Engine Logging

The DB class in db_engine.py features a configurable logging system. You can adjust the verbosity by modifying the log_level attribute:

| Level | Description | Usage | | :--- | :--- | :--- | | 0 | None | Disables all engine-level logging. | | 1 | Errors | Logs only failed operations and critical exceptions. | | 2 | All | Logs every successful query, connection, and data modification (Default). |

Session Auditing

The application monitors session activity to prevent unauthorized access. Technical logs are generated when:

• A session expires due to inactivity (configured via timeout_seconds in config.json).
• Malformed or invalid session data is detected.
• The root user is initialized or accessed.

API Usage for Logs

For programmatic access to audit data, the system provides endpoints that the frontend uses to populate the dashboard.

Fetching Key Logs

Retrieve a range of logs by providing Unix timestamps.

Endpoint: GET /api/keyLogs/list (Note: specific endpoint paths may vary based on blueprint registration).

Query Parameters:

• start_time: Unix timestamp for the beginning of the range.
• end_time: Unix timestamp for the end of the range.

Example Response:

[
    {
        "id": "123",
        "action": "Izsniegts",
        "keyNumber": "101",
        "at": "2025-05-20T10:30:00Z",
        "userName": "Jānis Bērziņš",
        "comment": "Room 204 usage"
    }
]

Configuration

To manage how long logs are kept or where session data is stored, refer to the config.json file:

{
    "client_sessions": {
        "timeout_seconds": 3600,
        "session_storage_dir": "%s/flask_session"
    },
    "db": {
        "db_file": "database.db"
    }
}

• Session Timeout: Adjust timeout_seconds to control how quickly the system logs out inactive users, creating a "Session timed out" audit event.
• Storage: All persistent logs are stored within the SQLite database defined in db_file. Ensure this file is backed up regularly to preserve the audit trail.