feat(admin): communications
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 33
- Forks
- 104
- Avg merge
- 12h 3m
- Merged PRs (30d)
- 10
Description
Summary
Email send capability for the admin app: newsletters, member notifications, event reminders, group announcements. Requires a transactional email provider decision.
Requirements
- Brainstorming → spec under
docs/superpowers/specs/. - Pick an email provider during brainstorm: Resend, Postmark, SendGrid, AWS SES, etc. Tradeoffs: cost at member volume (~3,700+), deliverability, bounce/complaint feedback, template management.
- Worker-side send adapter (
packages/api/src/lib/email/) abstracted from the provider so the choice is reversible. - Template management: stored as code in the repo (PR-reviewed) OR stored in DB (admin-editable). Decision part of brainstorm.
-
/admin/communications— composition surface, audience selector, send / schedule / preview, send history with delivery status. - Audience model: ad-hoc list (paste emails), saved segment ("all org members of tier X"), event-bound ("all attendees of event Y").
- Suppression list integration: respect bounces, complaints, and member-level marketing-consent flag (
users.marketing_consent). - Outbound email logged to
audit_logfor traceability ("who sent what to whom, when").
Context
Foundation must ship first (#1956). This subsystem unlocks event reminders (#1961), election notifications (#1964), and renewal nudges (#1959).
Implementation Notes
- Volume-pricing math matters: at ~3,700 members × monthly newsletter, providers price differently across the inflection points.
- Compliance: CAN-SPAM, GDPR if any EU members, plus respect
marketing_consent. Audit needs to capture the consent state at send time.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the foundation issue #1956 and the existing material under docs/superpowers/specs/. Map the proposed worker adapter in packages/api/src/lib/email/ to the /admin/communications surface, users.marketing_consent, and audit_log requirements. Done requires an agreed provider, template strategy, and complete support for composition, audiences, scheduling, delivery history, suppression, consent, and audit traceability.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend-api-design, documentation, full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100