# `PhoenixKit.Modules.Emails.Web.SettingsSections.DeliveryEventTracking`
[🔗](https://github.com/BeamLabEU/phoenix_kit_emails/blob/0.4.2/lib/phoenix_kit/modules/emails/web/settings_sections/delivery_event_tracking.ex#L1)

"Delivery event tracking" section on the core Email Sending settings
page (`/admin/settings/email-sending`) — the unified, registry-driven
admin panel from the universalization spec (`dev_docs/specs/
2026-07-26-email-event-tracking-universalization-spec.md` §5). One row
per `EventTrackerRegistry.trackers/0` entry; a new provider (Mailgun,
…) appears automatically once it registers, no panel code to touch.

Replaces the polling controls that used to live in the two separate
provider settings sections (`amazon_ses_sqs`, `brevo_events`) — see
those modules' moduledocs for what stayed behind (transport/identity
config, not polling).

## The expandable row

Every row expands to its own settings: the polling interval (generic —
every tracker has one) plus whatever the tracker names through
`EventTracker.settings_component/1`. SES points that at
`SettingsSections.AmazonSesSqs`, which used to be a third, sibling
section on this page — a peer of this table while actually being the
detail of one of its rows, duplicating its "is collection on" answer
and offering no clue which row it belonged to.

Expansion is an assign (`@expanded`, a MapSet of provider_kinds), not a
`<details>` or a daisyUI `collapse` checkbox: LiveView's morphdom patch
resets the DOM-only open state of both, so any row would snap shut on
the next poll-count refresh. Like the accounts dialog, the set is
re-resolved against fresh rows in `assign_rows/1` — the ONE place rows
are built — so a provider that disappeared (a tracker dropped by a
deploy) cannot leave an expanded row rendering against nothing.

## "Poll now" vs `poll_cycle/1`

`EventTracker.poll_cycle/1`'s own moduledoc anticipated this button
calling it directly (a synchronous, in-process cycle). This panel
calls each tracker's `poll_now/0` instead (see `EventTrackerRegistry`'s
duck-typed "Manager API"): it already exists, already handles the
"force a poll even while the toggle is off" case explicitly, and
enqueues via Oban rather than blocking the LiveView process for a
network round trip. `poll_cycle/1` stays defined (still satisfies the
behaviour) but unused here — a deliberate choice, not an oversight.

# `render`

---

*Consult [api-reference.md](api-reference.md) for complete listing*