feat(mf,mb): add mail service admin frontend - #126
Merged
Conversation
Introduce a complete mail frontend scaffold for campaign management: adds main entry (main.tsx), global styles (index.css), pages (Dashboard, CreateCampaign, CampaignDetail, EditCampaign), UI components (CampaignCard, ConfirmDialog, EmptyState, ExecutionHistory, HtmlEditor, HtmlPreview, Layout, LoadingSpinner, Pagination, ScheduleForm, Sidebar, StatusBadge), React hooks (useCampaign, useCampaigns, useTrigger), and supporting code (campaignService, types, formatDate utilities). Implements routing, form validation, HTML editor/preview, scheduling UI, execution history and trigger flows, and Turkish UI strings. This commit provides the initial client-side implementation to manage and execute email campaigns.
Add new mail admin pages/components and frontend config updates, and keep lockfile policy aligned by ignoring only package-lock.json. Made-with: Cursor
Update mail service config, campaign APIs, email processing, and related tests, and include backend lockfile updates for reproducible environments. Made-with: Cursor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
seberatolmez
changed the title
Member
Author
|
we’ll fix CORS once we identify the real production URL for the mail admin, and add it on the backend. |
DogukanUrker
approved these changes
Apr 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR does?
This pull request introduces a mail campaign admin experience in the monorepo and brings the mail service.
On the frontend, there is a new admin app for mail campaigns: operators can work through the main campaign lifecycle in one place—see what is scheduled, create and edit campaigns, run tests, and follow progress when sends are running—without hand-crafting API calls or ad-hoc scripts. The UI is wired to the existing mail API, uses the same stack conventions as the rest of the project (React, TypeScript, Vite, shared tooling), and is integrated into the root Makefile so install, lint, format, and a dedicated dev command stay consistent with form and the Python services.
On the backend, the mail service gains behavior that an admin product expects: stricter handling around who may call campaign APIs when an admin token is configured, clearer expectations in production configuration (including CORS and secrets), more dependable behavior around scheduling and long-running sends (including recovery from jobs that get stuck), and progress visibility suitable for polling from the UI. Existing flows such as unsubscribe remain public and are not folded behind admin auth. Tests are updated and extended so these paths stay guarded as the service evolves.
Repository hygiene: lockfiles for uv and bun are treated as first-class, versioned inputs so installs stay reproducible across machines and CI. Patterns that belong to other package managers we do not standardize on are kept out of the tree via
.gitignore, so accidental lockfile noise does not land in reviews.Together, this is a vertical slice: admin UI plus the API and operational hardening needed to run it safely, with documentation and tooling hooks so the feature is discoverable for anyone cloning the repo.
Checklist