[Feature]: Add operational Overview and audit activity logs to the Configuration Portal

[awatchar]

Component

Configuration portal

Problem to solve

The Configuration Portal currently includes navigation items for:

• Overview
• Devices
• Activity

However, only the Devices page currently provides functional content.

The Overview and Activity pages display only placeholder content:

Overview is quiet
Activity is quiet
Operational history will appear here as devices report state.

Administrators therefore cannot easily determine:

• How many devices are registered.
• Which devices have recently requested configuration.
• Which devices have never requested configuration.
• When a Device Profile was last changed.
• Which administrator made a change.
• What type of configuration was changed.
• Which configVersion was served to a device.
• Whether a device has fetched the latest configuration.
• When an unknown Device ID attempted to request configuration.
• When a device was registered, edited, or deleted.
• Whether the configuration storage service is operating normally.

The portal should provide an operational Overview and an audit/activity log that helps administrators understand what happened, which Device ID was affected, who performed the action, and when it occurred.

Current behavior

The portal currently stores Device Profile timestamps:

createdAt
updatedAt

However, it does not maintain a structured history of changes.

The public device configuration endpoints return configuration successfully but do not record:

• Last configuration request time
• Last configuration version served
• First successful configuration request
• Request count
• Configuration delivery history

The portal also does not record administrator actions such as:

• Device registration
• Configuration update
• Device deletion
• Pending-request dismissal
• Preset creation or modification
• Login and logout activity

Important terminology

The portal can confirm that a device requested and received an HTTP configuration response.

It cannot currently confirm that the Android application:

• Parsed the configuration successfully.
• Activated the configuration.
• Connected to the configured server.
• Joined the selected channel.
• Reached the Ready state.

The interface must therefore use precise wording such as:

Last config request
Last config served
Config version served

It must not label a device as Online, Applied, or Ready based only on a successful HTTP configuration response.

Confirming configuration activation would require a separate authenticated device acknowledgement mechanism and should not be inferred from a download request.

Desired outcome

Implement two functional operational views:

1. Overview — a concise dashboard showing the current state of the managed device fleet.
2. Activity — a searchable and filterable audit/operational log.

The existing Activity page can serve as the Log page. It may be labelled:

Activity

or:

Activity / Logs

A separate raw-log page is not required unless it provides capabilities beyond the Activity timeline.

Overview page

The Overview page should provide useful operational summaries without requiring the administrator to inspect each Device Profile.

Summary cards

Display at least:

• Total registered devices
• Devices that fetched config within the last 24 hours
• Devices that fetched config within the last 7 days
• Devices that have never fetched config
• Devices that have not fetched config recently
• Pending registration requests
• Configuration changes within the last 24 hours
• Configuration storage health

Example:

Registered devices           12
Config fetched in 24 hours    8
Never fetched config          2
Pending registrations         1
Recent config changes         3

Recent device configuration activity

Display a table containing:

• Device ID
• Display label
• Model
• Current stored configVersion
• Last configVersion served
• Last configuration request time
• Configuration-fetch status

Suggested statuses:

• Never fetched
• Fetched recently
• Fetched previously
• No recent fetch
• Fetch data unavailable

These statuses must describe configuration-request recency and must not imply network presence or application readiness.

Attention required

Display devices that may need administrator attention, including:

• Registered devices that have never fetched configuration.
• Devices whose last served version is older than the current stored version.
• Devices that have not fetched configuration within a configurable period.
• Pending requests from unknown Device IDs.
• Repeated pending requests.
• Configuration-storage errors.
• Devices with invalid or repair-required configuration.
• Devices whose configuration was recently changed but has not yet been requested.

Recent administrative changes

Display the latest successful administrator actions, such as:

• Device registered
• Configuration updated
• Device deleted
• Pending request dismissed
• Preset created or updated
• Release or portal settings changed, if such controls are added later

Each entry should show:

• Timestamp
• Administrator
• Action
• Device ID or resource
• Safe summary
• Result

Model distribution

Optionally display a small summary of registered hardware profiles:

T56     5
T99     3
RYKS    3
Generic 1

This is operational inventory information and must not be interpreted as hardware acceptance evidence.

Activity / Logs page

The Activity page should provide a chronological timeline of administrator and device-related events.

Event categories

Support at least the following categories:

Administrator events

• admin.login.succeeded
• admin.logout
• device.created
• device.updated
• device.deleted
• pending-request.dismissed
• preset.created
• preset.updated
• preset.deleted

Only include preset events when the reusable Configuration Library feature exists.

Device configuration events

• config.request.succeeded
• config.request.unknown-device
• config.request.invalid-device-id
• config.request.failed

System events

• storage.unavailable
• configuration.validation.failed
• activity-log.write.failed

Authentication failures may be recorded only under a privacy- and security-reviewed policy. Do not store attempted passwords, complete IP addresses, session cookies, or sensitive request contents.

Activity columns

Each event should display:

• Timestamp
• Category
• Action
• Actor
• Device ID or affected resource
• Result
• Safe summary
• Related configVersion, when applicable

Example entries:

Aug 12, 2026 16:20
Device AB12C3 requested config v12
Result: Served

Aug 12, 2026 15:42
Administrator awatchar updated Device GYZ3DE
Config version: v11 → v12
Changed: 1 server, 2 channels

Aug 12, 2026 15:10
Unknown Device AB12C3 requested configuration
Result: Not found

Aug 12, 2026 14:35
Administrator awatchar registered Device ZX98Y7
Model: T56

Search and filters

Allow administrators to filter by:

• Date and time range
• Device ID
• Display label
• Administrator
• Event category
• Action
• Result
• Model
• Config version

Provide quick time ranges:

• Last hour
• Last 24 hours
• Last 7 days
• Last 30 days
• Custom range

Pagination

Do not load the complete history into the browser at once.

The Activity API should provide:

• Server-side filtering
• Reverse chronological ordering
• Pagination
• A configurable result limit
• A maximum page size

Event details

Selecting an event may open a detail panel showing:

• Event ID
• Timestamp in UTC and the browser's local timezone
• Actor type
• Administrator username, when applicable
• Device ID
• Action
• Result
• Previous and new config versions
• Safe change summary
• Correlation or request ID, when available

The detail panel must not expose raw configuration, passwords, access tokens, bearer tokens, session cookies, signing material, exact private coordinates, or other secrets.

Device-level activity

Add operational metadata to the Device Profile view:

• First successful configuration request
• Last successful configuration request
• Last config version served
• Current stored config version
• Total