You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: consolidate workspace email on Mailjet - #200
Existing transactional email callers still depend on retired provider configuration, and administrators cannot configure the selected provider in Settings. This change adds an organization-scoped Mailjet adapter and a complete administrator Settings flow for encrypted credential storage, sender verification, explicit test send, editing, and disconnecting. Existing alert and manual debrief callers use this adapter; scheduled debrief copy accurately states that automation is paused.
The 21-file scope is one provider boundary change: server adapter, credential persistence, route, Settings controls, existing callers, additive provider enum, and tests. It does not add customer campaigns, activate scheduled sends, remove historical tables, or change access policy.
Validation: npm run verify passed 60 test files / 263 tests, lint, types, Prisma validation, and build on main e4732d2 plus this change. Real Chromium checks passed the mobile Settings workflow and dashboard PDF download. Provider network, response validation, encryption, and admin/org guards have focused tests. Settings browser tests use controlled provider responses; live provider acceptance and inbox delivery require a separate configured-account test.
Release considerations: additive enum and dedicated encryption configuration are required. Missing configuration produces an explicit setup state. Provider failures are bounded and surfaced without automatic duplicate-send retries.
@bryce approval requested: Approve the additive MAILJET provider enum migration, creation of a dedicated deployment encryption secret, and release of the validated Mailjet Settings integration; real credentials will be entered through Settings and no customer email or scheduled delivery will be activated.
Additional regression proof: npm run test:e2e -- tests/e2e/mailjet-settings.spec.ts passed in the local mobile viewport. The test uses controlled provider responses and sends no external email. Exact implementation head 4001d13 has successful CI and Vercel preview checks. Release remains approval-gated for schema and encryption-secret setup.
Release validation is being refreshed on current main. The release adds the MAILJET provider enum and a dedicated encryption key for stored credentials. It does not activate scheduled email. Live provider validation remains separate from the passing fixture-based UI tests.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.
Additional browser validation: all eight contact-workspace scenarios now pass across the final focused runs, including Gmail retry/disconnect, manual debrief recipient saving with scheduling paused, contact creation, Gmail suggestions, and account follow-up actions. Fixtures use example identities and reserved addresses. The application source remains the same tree that passed all 263 unit/integration tests and the full build.
Released main 2280256 to https://piccnewyork.org, deployment dpl_3c1Lb4dvMth6CgbzSw4dqtXiZxvz READY. Authenticated production Settings now renders Mailjet and the paused-scheduling/manual-debrief controls. Live credential validation and recipient delivery are still pending configuration; no live provider send has been claimed.
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
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.
brycejohnson1417
changed the title
Closes #199.
Existing transactional email callers still depend on retired provider configuration, and administrators cannot configure the selected provider in Settings. This change adds an organization-scoped Mailjet adapter and a complete administrator Settings flow for encrypted credential storage, sender verification, explicit test send, editing, and disconnecting. Existing alert and manual debrief callers use this adapter; scheduled debrief copy accurately states that automation is paused.
The 21-file scope is one provider boundary change: server adapter, credential persistence, route, Settings controls, existing callers, additive provider enum, and tests. It does not add customer campaigns, activate scheduled sends, remove historical tables, or change access policy.
Validation:
npm run verifypassed 60 test files / 263 tests, lint, types, Prisma validation, and build on main e4732d2 plus this change. Real Chromium checks passed the mobile Settings workflow and dashboard PDF download. Provider network, response validation, encryption, and admin/org guards have focused tests. Settings browser tests use controlled provider responses; live provider acceptance and inbox delivery require a separate configured-account test.Release considerations: additive enum and dedicated encryption configuration are required. Missing configuration produces an explicit setup state. Provider failures are bounded and surfaced without automatic duplicate-send retries.