Filament Presence Laravel Package

Technical Evaluation

Architecture fit: happenv-com/filament-presence is a Filament panel plugin that surfaces live user-session presence (who's online, active sessions) inside the admin UI. It is a thin, additive layer over an existing Laravel + Filament application: it does not alter auth, session drivers, or broadcasting configuration, so it slots into the presentation tier rather than the core domain. v1.2.0 adds hideWhen(), a per-indicator conditional-visibility hook that lets teams suppress presence display for specific sessions (e.g. impersonated admins, service accounts, or internal-only users). This is a policy/display concern exposed as a fluent configuration method — architecturally consistent with Filament's existing visible()/hidden() idioms, which lowers the conceptual cost of adoption.

Integration feasibility: High. The API surface in this release is a single additive method on the indicator/session definition, callable from panel or widget configuration. No new services, migrations, or config publishing appear to be required. The only other change is a CI dependency bump (TruffleHog 3.97.5 → 3.97.9) in the GitHub Actions pipeline — build-time only, zero runtime footprint for consumers.

Technical risk: Low. The release is a minor version bump with one feature and one CI-only dependency update; nothing indicates a schema, config-key, or method-signature break. The residual risks are the usual ones for this class of package: presence data is only as accurate as the underlying session/broadcast mechanism, and hiding the indicator is a UI affordance, not an authorization control — it must not be mistaken for access restriction. hideWhen() is also new enough that edge cases (evaluation timing, closure binding, behaviour under Livewire polling) are unproven in the field.

Key questions:

• Does hideWhen() accept a closure with access to the session/user context, and is it evaluated per render or per poll?
• Are presence reads backed by the database session driver, a cache, or broadcasting — and what is the query/poll cost at our expected concurrency?
• Confirm whether hidden indicators still incur the underlying presence lookup cost.
• Is there a published support policy / maintainer bandwidth signal for this vendor (happenv-com)?
• Does the package declare a Filament major-version constraint compatible with our pinned version?

Integration Approach

Stack fit: Requires Laravel with Filament (v3-era conventions implied by the fluent visibility API). Fits our stack provided we are already on a supported Filament major and are not running a heavily customised panel that would conflict with the plugin's widget registrations.

Migration path: Greenfield — no prior assessment exists and no legacy presence implementation is described. Adoption is a composer require plus panel-plugin registration, then incrementally adopting hideWhen() for session classes we do not want surfaced. Because the feature is opt-in per indicator, we can ship the plugin with presence visible everywhere and tighten visibility afterwards, rather than gating rollout on policy decisions.

Compatibility: Semver-minor release; treat as backward compatible with v1.1.x. The only dependency change is confined to the project's own CI workflow and does not propagate to consumers. Verify our Filament and PHP version constraints against the package's composer.json before pinning — this is the single most likely source of integration friction.

Sequencing:

1. Pin ^1.2.0 in a non-production environment; validate panel boot and widget rendering.
2. Confirm presence data source and measure polling/query load under realistic session counts.
3. Define the visibility policy — which session types get hideWhen() — with security and compliance input.
4. Roll out to an internal/staging panel first; observe for a full working week.
5. Promote to production with the visibility policy applied from day one rather than retrofitted.

Operational Impact

Maintenance: Low ongoing burden. The package is small and single-purpose; the release cadence visible here (patch → minor with one feature, plus automated dependency hygiene) suggests an actively maintained but lightweight project. Budget a periodic review of upstream releases and a Filament-major upgrade checkpoint, which is where this class of plugin typically requires intervention.

Support: No commercial support implied. Dependence is on a single maintainer (@webard) and a small contributor base — the first-time Dependabot contribution in this release is a maintenance signal, not a depth-of-bench signal. Mitigation: keep the integration shallow (configuration only, no forks, no patching of vendor internals) so it can be replaced or removed within a sprint.

Scaling: The scaling characteristic to watch is presence read cost, not the plugin's code. Presence queries and Livewire polling scale with concurrent admin users, not end users, which typically keeps absolute numbers modest. Confirm behaviour if the panel is exposed to a large internal user base or if presence is rendered on high-traffic dashboards; if so, consider polling-interval tuning or restricting the widget to specific panels.

Failure modes:

• Stale presence — sessions not cleaned up, showing phantom online users; degrades trust in the indicator.
• Visibility leak — hideWhen() misconfigured, exposing sessions the policy intended to conceal; treat as a security-relevant misconfiguration and cover with a test.
• Filament upgrade breakage — plugin pinned to an older Filament major; manifests as panel boot or widget render failure after a framework bump.
• Polling load — presence refresh driving excess queries on dashboards; surfaces as latency, not errors.
• Abandonment — upstream goes quiet; no runtime failure, but an eventual forced migration.

Ramp-up: Minimal for a Laravel/Filament-fluent team — the API mirrors native Filament visibility conventions, so a developer can be productive in under a day. The real ramp-up cost sits with whoever owns the visibility policy, since deciding which sessions to hide requires knowledge of impersonation flows, service accounts, and internal-vs-external user segmentation. Document that policy alongside the configuration so it survives maintainer turnover.