The Event Viewer is a redeveloped, modern screen for real-time monitoring of all system events in TestLink. It replaces the legacy event viewer with a clean HTML+JavaScript interface powered by its own BFF (Backend-for-Frontend) API.

Path: System > Event Viewer
URL: gui/templates/eventviewer/eventviewer.html
Prerequisite: You must be logged in with the mgt_view_events right (all users by default).

1. Screen Layout
2. Filters
3. Charts
4. Events Table
5. Row Detail View
6. Delete Events
7. Rights & Access Control
8. API Endpoints
9. Color Scheme

The page is divided into four horizontal sections:

No iframes, no PHP rendering, no Smarty templates — pure static HTML with JavaScript calling the BFF API.

The filter bar sits at the top and allows narrowing down the displayed events. All filters are applied server-side via query string parameters.

Note: The date pickers use the daterangepicker library but are configured to accept a single date per field (From and To), not a range.

Two charts provide a visual overview of event distribution:

• Shows the count and percentage of events for each log level
• Color-coded to match the level badges in the table
• Includes an inline legend on the right side of the chart
• Uses Chart.js v1 Doughnut with 45% inner cutout

• Shows the number of events per day over the last 30 days
• Area-filled line chart with the TestLink teal accent color
• Automatically generated from the filtered dataset
• Uses Chart.js v1 Line with bezier curves
• Hover tooltip: moving the pointer over a plotted point shows a dark tooltip with the date and event count (e.g. 2026-09-04: 2), matching the doughnut chart's tooltip. Implemented in gui/templates/dashio/lib/tl-line-tooltip.js because the bundled Chart.js v1 build has no native tooltip support.

Both charts update whenever the Apply button is clicked with new filter settings.

A DataTables-powered table listing all matching events. By default the rows are grouped by Log Level into collapsible groups (data ordered by level, then by timestamp descending — newest first within each group), mirroring the legacy ExtTable grouping (eventviewer.legacy.php:263-274, setGroupByColumnName(th_loglevel) + sortDirection=DESC).

A toolbar sits directly above the table with three actions plus a status badge:

Clicking an individual group header row toggles that group's expand/collapse state. Level groups show their element count, e.g. ERROR (2 items).

• Pagination: 25 rows per page by default
• Grouping: Rows are grouped by Log Level (uses the DataTables RowGroup extension, rowGroup.dataSrc). Within each group rows sort by timestamp descending.
• Group collapse: Click a group header to collapse/expand that level; use the toolbar to expand or collapse all at once.
• Sorting: Click any column header (except expand and description) to sort ascending/descending. The Timestamp column sorts chronologically by the numeric epoch, not by the dd/mm/yyyy display string — the column cell carries [epoch, formatted] and an orthogonal render(data,type) returns the epoch for the sort type (legacy hidden-<!--epoch-->-comment parity, eventviewer.legacy.php:241-243). This keeps month/year boundaries correct (e.g. a 31/07/2025 event sorts before a 04/08/2026 one in ascending order) in both directions.
• Search: Use the DataTables search box to filter the visible rows client-side
• Row expand: Click the chevron icon or the description text to expand/collapse the detail row

Ascending sort by Timestamp — chronological across month/year boundaries (31/07/2025 before 06/06/2026 before 04/08/2026 …), verified with seeded events from the legacy gap report (Refs #874):

(Before the fix the same click sorted by the dd/mm/yyyy string — 04/08/2026, 04/09/2026, 06/06/2026, 09/09/2026, 31/07/2025 — see issue-874-string-sort-before.png.)

When the current filter set matches zero events (e.g. a date range entirely in the future), the page reproduces the legacy behavior (lib/events/eventviewer.legacy.php:72-74 → eventviewer.tpl:184-198): the events table and its toolbar are hidden and a localized "No events found." feedback box is shown in their place (#noEventsBox, white card with a teal left border and info icon). The message is routed through TLi18n.t('ev.noEvents'), so it renders per-locale — e.g. "Nu au fost găsite evenimente." in Romanian, "Keine Ereignisse gefunden." in German.

The DataTables engine strings are also localized for the same condition:

• emptyTable (server-side empty result in the hidden grid),
• infoEmpty (the info/footer line),
• zeroRecords (a client-side search box query that matches nothing).

All three point at ev.noEvents, present in all 10 locale bundles.

Expanding a row reveals the complete event record (legacy eventinfo.tpl parity) in a bordered detail panel:

The detail data is fetched on-demand via GET /api/eventviewer/index.php/events/{id}.

Users with the events_mgt right (typically admins) see a Clear Events button in the filter bar.

• Clicking the button shows a confirmation dialog: "Delete events matching current filters?"
• Events are deleted based on the currently selected log level filter
• If no log levels are selected, all events are deleted (use with caution)
• After deletion, the table and charts reload automatically
• All filters are reset after a successful delete (legacy BUGID 3908 parity, lib/events/eventviewer.legacy.php:44-50): the Log Levels, User(s), From and To controls are cleared so the full event log is re-shown with no stale filter. The Date controls are reset in JS as well. Only the per-object drill-down filter (when opened via "Show event history") is preserved, since it is a page-level context rather than a user-adjustable filter.
• The button is hidden for users without the events_mgt right

Audit trail (legacy parity): every deletion is itself audited — the BFF calls logAuditEvent() right after deleteEventsFor(), so the Event Viewer history stays traceable:

• No log level selected → TLS("audit_all_events_deleted", login) → "User 'admin' deleted all events"
• Specific levels selected → TLS("audit_events_with_level_deleted", login, levelNames) → "User 'admin' deleted events with level: Error,Warning,Info,Debug,Audit,L18N"

Both rows are written with log level AUDIT, source events, and activity code DELETE. This mirrors lib/events/eventviewer.legacy.php:27-43.

In legacy TestLink 1.9.20, lib/events/eventviewer.php was gated by testlinkInitPage(...checkRights) — a user without the mgt_view_events right received an access-denied screen, and even direct URL access was blocked. lib/events/eventinfo.php (row detail) required the same right; only the clear action (events deletion) could be reached via events_mgt alone. The Events menu item in the top bar is rendered only for users holding events_mgt OR mgt_view_events (cfg/const.inc.php:908).

The modern screen reproduces this exactly:

The access-denied panel is an i18n block (ev.accessDeniedTitle / ev.accessDeniedMsg) shown by the UI as soon as the /events/meta/rights probe is rejected (or fails) — even a user who deep-links directly to eventviewer.html without the right gets the panel and no data calls fire.

The Event Viewer uses a dedicated BFF API at /api/eventviewer/index.php. All endpoints require an authenticated session, and all read (GET/HEAD/OPTIONS) routes additionally require the mgt_view_events right — they return 403 Forbidden when it is missing. The only route gated by a different right is DELETE /events, which requires events_mgt.

{
  "id": 42,
  "timestamp": 1692000000,
  "timestampFormatted": "15/08/2023 14:00:00",
  "logLevelCode": 3,
  "logLevel": "INFO",
  "description": "User admin logged in",
  "source": "login",
  "userID": 1,
  "userName": "admin",
  "userDisplayName": "Administrator",
  "transactionID": 12345,
  "sessionID": "qun27mjdmgqeerpm1ds5gn0lfk",
  "objectID": 1,
  "objectType": "users",
  "activityCode": "login"
}

The Event Viewer uses the standard Dashio color palette: