rConfig Vector Prism – Key Features

rConfig Vector Prism Key Features: Complete Catalogue

This is a curated catalogue of every customer-facing feature in rConfig Prism. Each entry includes a short description and (where relevant) a pointer to the in-app deeper documentation at /admin/docs inside your Prism instance.

Multi-Tenant Customer Portal

Per-team isolation. Each customer is a team. Each team has zero or more rConfig tags mapped to it. The portal renders only the devices and configurations matching the team’s tag scope, with the gate enforced server-side — a customer cannot URL-hack to a device that isn’t in their scope. Empty mapping fails closed (zero devices visible).

No data duplication. Prism does not store devices or config payloads in its own database. Every list and every body is fetched live from rConfig (with caching) and filtered to the team scope before rendering.

Workspace switcher (optional). A user belonging to multiple teams sees a workspace switcher in the portal sidebar so they can move between team scopes without signing out.

White-Label Branding

Instance-wide branding. Logos (light + dark + login + favicon), login background image with zoom and opacity, primary and accent colours with WCAG contrast indicator, heading and body fonts, border radius scale, default colour scheme, instance name and short name, support email and URL, footer text, login copy (message, headline, subline), promo card (title, body, CTA), “Powered by rConfig” toggle.

Per-team override. When enabled instance-wide, each team can override every brand field. The portal renders the team’s brand; the admin surface always uses the instance brand to keep the operator perspective consistent.

Live preview. The brand editor previews both the login screen and a dashboard tile so you can see your changes before saving.

Brand presets. Save the current settings as a named preset and reapply later — useful when you want a “starter” brand for new customers.

SVG sanitisation. Logo and favicon uploads run through an SVG sanitiser that rejects external references, scripts, and embeds. If a logo is rejected, the source SVG contains unsafe content; ask for a clean export or a PNG/JPG instead.

Authentication and Account Security

Mandatory TOTP 2FA. Every user — admin and customer — must enrol an authenticator app before the system is usable. Recovery codes are issued at enrolment.

Session pinning. Prism uses Jetstream’s session-pinning so a stolen cookie can’t survive a password change. Sessions are tied to the user’s password hash.

Account lockout. Too many failed sign-ins lock the account temporarily and queue an alert email to the user. Tunable per Jetstream config.

Password reset. Standard “forgot password” flow with a 1-hour expiry link, queued.

2FA reset. Admins can reset a user’s 2FA from the user list; the user is sent through enrolment again on next sign-in.

Session list. Users can see and terminate their active sessions from the profile page.

Audit Trails

Action audit (/admin/audit-log). Every admin change recorded with timestamp, IP, user agent, and before/after metadata. Examples: team created, user invited, tag mapping added or removed, brand setting saved, 2FA reset for user, user disabled.

Access audit (/admin/access-audit). Every login attempt and every permission denial recorded. Useful for security review and incident response.

Filters and export. Both logs filter by action, user, and date range. CSV export is built in.

Retention. Configurable in System Settings. Defaults: 730 days (action audit), 90 days (access audit). A daily scheduled job purges rows older than the window. Manual bulk purge by date range is also available.

Exception Alerting

Email on unhandled error. When a 5xx (or other configured status) lands, Prism queues a branded email with stack trace and request context to your operator address.

Deduplication. Identical exceptions (same class, message, file:line) within a day increment a counter rather than spawning duplicate emails or rows.

Throttling. Configurable window (recommend 15 minutes minimum) so a bug in a hot loop doesn’t flood your inbox.

Status filter. Only the HTTP statuses you choose trigger an alert. Default: 413,500,502,503,504.

Test button. A “Send test exception alert” button in System Settings → Exception Alerts queues a mock alert so you can verify the recipient and routing.

Exception log viewer. /admin/exception-logs shows open and resolved exceptions with full traces. Mark resolved/reopen individually. Bulk purge by age.

API Integration with rConfig

Endpoint registry. All rConfig API paths Prism uses live in a single registry, so a future API version bump only changes one file. Endpoints currently include: tags, devices, device, device configs, single config, health latest.

Two-tier cache.

Hot cache — short-lived (default 5 minutes) positive cache absorbs request bursts and brief network hiccups.
Last-good cache — long fallback (default 1 day) only served when the hot cache misses and the upstream fails. Customers see a “data may be out of date” badge with the cached-at timestamp.

Circuit breaker. After consecutive failures, the breaker opens and short-circuits all requests for a configurable cool-down. Single-config-body fetches (which can’t fall back to a list cache) return 503 with a friendly “Connection is down” page. List views fall back to last-good.

Health probe. A health endpoint check feeds the dashboard’s API failure card. Operators see failure counts in 24-hour, 7-day, 30-day, and all-time windows.

Request log (/admin/rconfig-api-logs). Every Prism → rConfig HTTP call recorded: endpoint, method, response time, status, cache hit/miss flag. Filterable, exportable, purgeable.

System time probe. A separate uncached probe extracts the rConfig server’s wall clock from the HTTP Date response header so the sidebar widget can compare Prism’s and rConfig’s clocks.

For the full integration architecture, see /admin/docs/features/rconfig-api-caching inside your running instance.

Locale and Timezone

Single instance-wide setting. One BCP-47 locale and one IANA timezone govern every date and time render across the UI, audit logs, and email templates.

No per-user override by design. A screenshot from one operator should match what every other operator sees in the logs. The single source of truth eliminates “it’s 9 AM for me but the log says 14:00” confusion.

Curated locale picker. A vetted list of locales with friendly labels rather than the full unicode CLDR catalogue.

150+ timezones. Full IANA timezone catalogue.

The sidebar’s top-left clock shows the current Prism time in your locale and timezone. Click for a popover comparing Prism vs rConfig server clocks. A diff of more than a second triggers a warning badge — usually a signal that NTP needs attention upstream.

Theme Toggle

Light, dark, or system (follows OS appearance). User preference persisted in browser localStorage. Class-based dark mode means semantic tokens flip cleanly between themes; no dark: utility sprinkling.

Operator Onboarding Checklist

A gamified twelve-task checklist on the admin dashboard guides new operators through:

Customizing branding.
Configuring mail server.
Connecting to rConfig API.
Setting locale and timezone.
Running system optimization.
Verifying queue manager (Horizon).
Adding a backup admin.
Rotating seeded admin credentials.
Reviewing operator security hardening.
Creating the first customer.
Inviting the first customer user.
Mapping customer tags.

Most tasks auto-complete the moment Prism detects the underlying work is done. A few (queue manager, optimization review, security hardening) are manual ticks. Progress is shown as a ring + percent + “X of Y complete”. On completion, the dashboard shows a “production ready” banner.

The checklist can be dismissed and re-opened from the sidebar. See Getting Started for the full walkthrough.

In-App Help Center

/admin/docs inside the running Prism instance is a markdown-driven operator manual with hierarchical navigation. Topics include version-specific runbooks, security hardening checklists, exception alert tuning, audit retention recipes, brand-setting cookbook, impersonation operator guide, and more.

The in-app docs are version-locked to your install; this Astro doc site is the public marketing-and-orientation surface.

Custom Impersonation

Admin can search for any user and step into their session for support, without that user’s password and without re-issuing 2FA on either transition. An amber banner across the top of the page makes it obvious you’re impersonating; a one-click “Stop impersonating” returns to your admin session.

Both the start and stop transitions are written to a dedicated impersonation audit (admin email, target email, IP, user agent, started at, ended at). Nested impersonation is rejected.

A full operator runbook (including SQL queries to retrieve past sessions for compliance or support) lives at /admin/docs/features/impersonation.

Mail Pipeline

Always queued. Every outbound mail goes through the queue. A slow or unreachable SMTP relay never extends a request’s response time, and an exception raised mid-render never cascades into a synchronous mail attempt.

Branded transactional templates. Invitations, password resets, 2FA reset notifications, lockout alerts — all use the team brand if available, falling back to the instance brand.

Test send. Both the mail server tab and the exception alerts tab have test-send buttons that queue a mock message so you can verify routing without breaking the platform.

DB-backed config. Mail server config (host, port, credentials, encryption) is stored in the database, not in .env. Edit it from System Settings; no deployment needed. Empty config falls back to .env defaults for development.

System Optimization

/admin/optimization reads your PHP runtime configuration and scores it against production recommendations: opcache, JIT, memory limit, max execution time, post max size, realpath cache. Each row passes, warns, or fails with a linked doc explaining why and what value to set.

Operator Dashboard Health Snapshot

The admin dashboard surfaces a notification panel with actionable signals from the past 24 hours (configurable window):

API failures detected upstream.
Open exceptions.
Recent permission denials.
Mail server health.
Onboarding progress.

Each item links into the relevant management screen plus, where applicable, a contextual /admin/docs page.

Right to access (data export). Users can self-serve a ZIP export of their profile and audit trail from /account/data-export. The job is queued; the user receives an email when ready.

Right to erasure. Admins can hard-delete a user from the user list. Audit rows persist (showing the email at action time) but the account is gone.

Retention policies. Configurable retention for the action audit and access audit logs, with automatic daily purge.

Soft-lock vs hard-delete. Disabled users keep their data for off-boarding investigation; deleted users are gone.

How the Pieces Fit Together

A typical Prism deployment has these moving parts:

Two user populations — operators (Prism admins) and customer users from each tenant. Both authenticate over HTTPS with mandatory 2FA.
Two UI surfaces — the admin surface at /admin/* (operator-only) and the customer portal at /dashboard, /devices, and /configs (every authenticated user).
Prism core — the tag-scope gate, cache, audit pipeline, and brand resolver that every request flows through.
rConfig server — the upstream source of truth for devices and configurations. Prism reaches it via cached HTTP calls over the rConfig API (v1 + v2).
Operational telemetry — audit log + access audit, exception logs, and the rConfig API request log, all written by Prism core for operator review.
Mail pipeline — every outbound mail is queued and dispatched to your configured SMTP relay; nothing sends synchronously.

Overview — What Prism is.
Admin Guide — How operators use these features day-to-day.
Portal Guide — How customers use the portal.
Best Practices — How to get the most out of these features.
Troubleshooting — When features misbehave.