Bỏ qua để đến nội dung
LionPOS

Client events & UI errors (Admin)

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

Executive summary

Section titled “Executive summary”

The Client events screen (/dashboard/client-events in admin-web) lists browser-side events ingested by the API: JavaScript errors, React error-boundary captures, and optional usage signals. Events are stored in ui_client_events (run the backend migration that creates this table before relying on the UI).

Who can use it

Section titled “Who can use it”
  • Master Admin and staff with access to the System area (sidebar Client events).
  • Data is not zone-scoped by store: it is a global operational view for triage.

What gets recorded

Section titled “What gets recorded”
  • Admin web and vendor web ship a small telemetry client that POSTs anonymized payloads when configured (global error handlers, optional reporting helpers, React error boundary on admin).
  • Typical kind values include js_error, react_error_boundary, unhandledrejection, and custom / usage-style events depending on product wiring.
  • severity helps filter noise (error vs info).

Operations checklist

Section titled “Operations checklist”
  1. Apply the NestJS migration that adds ui_client_events and indexes (including resolved_at, resolved_by_admin_id when present in your branch).
  2. Confirm admin JWT can call the admin list/detail routes used by the dashboard (see backend UiTelemetry / AdminUiClientEventsController in code).
  3. Open Dashboard → System → Client events; use URL-synced filters (source, kind, severity, date range, errors-only), All / Open / Resolved tabs, free-text search, and pagination (same pattern as Orders).

Resolve and delete

Section titled “Resolve and delete”
  • Single event: on the detail page, use Mark resolved (open events only) or Delete (with confirmation). Delete returns to the list.
  • Batch: on the list, select rows (up to 200), then Mark resolved or Delete (with confirmation).
  • Manual report: Report event opens a form to ingest a row (for staging reproductions).

HTTP routes (admin, JWT):

  • POST /auth/admin/ui-client-events/:id/resolve — set resolved metadata for one row.
  • POST /auth/admin/ui-client-events/batch/resolve — body { ids: string[] }.
  • DELETE /auth/admin/ui-client-events/:id — hard delete one row.
  • POST /auth/admin/ui-client-events/batch/delete — body { ids: string[] }.

List query supports tab=all|open|resolved in addition to existing filter query parameters.

Privacy and retention

Section titled “Privacy and retention”
  • Payloads may contain URLs and stack traces; treat rows as internal diagnostics, not end-user PII storage.
  • Long-term retention / purge policy should be defined by ops (not enforced by the first UI iteration).
Section titled “Related”