Documentation
¶
Overview ¶
Package notifywire assembles the notification substrate for the HTTP composition root: the delivery handle, the branded templates, the review and connection alerts, and the portal's notifier and self-scoped preference routes.
It was extracted from internal/httpserver (#1759) when that package reached its size budget. The seam is a real one: everything here takes a *platform.Platform and returns an assembled subsystem handle, and nothing in it touches a mux, a route or a middleware, which is what the composition root itself is about.
Index ¶
- Constants
- func APIConnectionExists(reg *registry.Registry) func(context.Context, string) bool
- func BuildNotifications(p *platform.Platform, brand Brand) *notifydelivery.Handle
- func ChannelUpstream(reg *registry.Registry) notifypost.UpstreamFunc
- func RunPosts(p *platform.Platform) postshttp.PostReader
- func WirePortalNotifications(deps *portal.Deps, p *platform.Platform, notify *notifydelivery.Handle, ...)
- type Brand
Constants ¶
const PortalToolkitKind = "portal"
PortalToolkitKind is the registry kind of the asset-portal toolkit.
Variables ¶
This section is empty.
Functions ¶
func APIConnectionExists ¶ added in v1.134.0
APIConnectionExists reports whether a live api toolkit serves a connection. The admin channel form uses it to warn about a channel naming a connection nothing serves, which is otherwise a channel that looks configured and fails only when something is sent to it.
func BuildNotifications ¶
func BuildNotifications(p *platform.Platform, brand Brand) *notifydelivery.Handle
BuildNotifications assembles the email-notification substrate from the platform's database, encryptor, and the brand supplied. Returns nil when the feature is unavailable (no platform, no database) or disabled by config; every consumer of the handle is nil-safe.
func ChannelUpstream ¶ added in v1.134.0
func ChannelUpstream(reg *registry.Registry) notifypost.UpstreamFunc
ChannelUpstream resolves the api connection a chat or webhook channel delivers through to its authorized transport (#1720).
The registry is walked per send rather than snapshotted, for the reason the api browser's locator walks it per request: a connection added or re-keyed through the admin API is reachable without a restart, and a channel holding a transport built at startup would keep posting with a credential the operator has already rotated.
Returns nil when there is no registry to walk, which leaves the three HTTP channel kinds undeliverable rather than silently failing per send.
func RunPosts ¶ added in v1.143.0
func RunPosts(p *platform.Platform) postshttp.PostReader
RunPosts reads a managed-script run's posts from the notification queue (#1723), or nil when this deployment has no notifications to read them from. The explicit nil keeps a typed nil out of the interface.
func WirePortalNotifications ¶
func WirePortalNotifications(deps *portal.Deps, p *platform.Platform, notify *notifydelivery.Handle, audience *mention.Audience)
WirePortalNotifications attaches the notification substrate to the portal dependency set: the share/thread trigger bridge and the self-scoped preference routes. A nil handle leaves both unset (feature unavailable).
The mention audience is supplied rather than built here: the composition root builds one and hands the same one to every surface that resolves a mention.
Types ¶
type Brand ¶
type Brand struct {
// Name is the deployment's brand name, already resolved through its
// fallbacks.
Name string
// UnsubscribeURL builds the no-login opt-out link for an address, or nil
// when the endpoint cannot be served.
UnsubscribeURL func(email string) string
}
Brand is what an email says it is from and where its footer links go. The composition root resolves both -- the brand name has fallbacks that belong to the portal's config, and the unsubscribe link needs the browser-session signing key -- so they arrive here rather than being derived twice.
Source Files