Files
pn-new-crm/src/components/shared/branded-auth-shell.tsx

63 lines
2.5 KiB
TypeScript
Raw Normal View History

feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
const DEFAULT_BG_URL = 'https://s3.portnimara.com/images/Overhead_1_blur.png';
const DEFAULT_LOGO_URL =
'https://s3.portnimara.com/images/Port%20Nimara%20New%20Logo-Circular%20Frame_250px.png';
feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
interface BrandedAuthShellProps {
children: React.ReactNode;
/** Per-port branding override resolved server-side by the page that
* renders the shell. When omitted, falls back to the Port Nimara
* defaults so single-tenant deployments remain unaffected. Pages
* that know their portId at render time should pass the result of
* `getPortBrandingConfig(portId)`. */
branding?: {
logoUrl?: string | null;
appName?: string | null;
};
}
feat(platform): residential module + admin UI + reliability fixes Residential platform - New schema: residentialClients, residentialInterests (separate from marina/yacht clients) with migration 0010 - Service layer with CRUD + audit + sockets + per-port portal toggle - v1 + public API routes (/api/v1/residential/*, /api/public/residential-inquiries) - List + detail pages with inline editing for clients and interests - Per-user residentialAccess toggle on userPortRoles (migration 0011) - Permission keys: residential_clients, residential_interests - Sidebar nav + role form integration - Smoke spec covering page loads, UI create flow, public endpoint Admin & shared UI - Admin → Forms (form templates CRUD) with validators + service - Notification preferences page (in-app + email per type) - Email composition + accounts list + threads view - Branded auth shell shared across CRM + portal auth surfaces - Inline editing extended to yacht/company/interest detail pages - InlineTagEditor + per-entity tags endpoints (yachts, companies) - Notes service polymorphic across clients/interests/yachts/companies - Client list columns: yachtCount + companyCount badges - Reservation file-download via presigned URL (replaces stale <a href>) Route handler refactor - Extracted yachts/companies/berths reservation handlers to sibling handlers.ts files (Next.js 15 route.ts only allows specific exports) Reliability fixes - apiFetch double-stringify bug fixed across 13 components (apiFetch already JSON.stringifies its body; passing a stringified body produced double-encoded JSON which failed zod validation) - SocketProvider gated behind useSyncExternalStore-based mount check to avoid useSession() SSR crashes under React 19 + Next 15 - apiFetch falls back to URL-pathname → port-id resolution when the Zustand store hasn't hydrated yet (fresh contexts, e2e tests) - CRM invite flow (schema, service, route, email, dev script) - Dashboard route → [portSlug]/dashboard/page.tsx + redirect - Document the dev-server restart-after-migration gotcha in CLAUDE.md Tests - 5-case residential smoke spec - Integration test updates for new service signatures Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 21:54:32 +02:00
/**
* Branded shell shared by every auth/form surface - CRM login, portal login,
feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
* password set/reset/activate, forgot-password. Renders the blurred
* background, the logo, and a centered white card that consumers
* populate with their own form/content.
*
* Multi-tenant note (R2-H15): the per-port logoUrl from
* /admin/branding is rendered when the parent page passes a `branding`
* prop. The background image stays as the marina default for all
* deployments admin-authored backgrounds aren't part of the v1
* branding surface.
feat(platform): residential module + admin UI + reliability fixes Residential platform - New schema: residentialClients, residentialInterests (separate from marina/yacht clients) with migration 0010 - Service layer with CRUD + audit + sockets + per-port portal toggle - v1 + public API routes (/api/v1/residential/*, /api/public/residential-inquiries) - List + detail pages with inline editing for clients and interests - Per-user residentialAccess toggle on userPortRoles (migration 0011) - Permission keys: residential_clients, residential_interests - Sidebar nav + role form integration - Smoke spec covering page loads, UI create flow, public endpoint Admin & shared UI - Admin → Forms (form templates CRUD) with validators + service - Notification preferences page (in-app + email per type) - Email composition + accounts list + threads view - Branded auth shell shared across CRM + portal auth surfaces - Inline editing extended to yacht/company/interest detail pages - InlineTagEditor + per-entity tags endpoints (yachts, companies) - Notes service polymorphic across clients/interests/yachts/companies - Client list columns: yachtCount + companyCount badges - Reservation file-download via presigned URL (replaces stale <a href>) Route handler refactor - Extracted yachts/companies/berths reservation handlers to sibling handlers.ts files (Next.js 15 route.ts only allows specific exports) Reliability fixes - apiFetch double-stringify bug fixed across 13 components (apiFetch already JSON.stringifies its body; passing a stringified body produced double-encoded JSON which failed zod validation) - SocketProvider gated behind useSyncExternalStore-based mount check to avoid useSession() SSR crashes under React 19 + Next 15 - apiFetch falls back to URL-pathname → port-id resolution when the Zustand store hasn't hydrated yet (fresh contexts, e2e tests) - CRM invite flow (schema, service, route, email, dev script) - Dashboard route → [portSlug]/dashboard/page.tsx + redirect - Document the dev-server restart-after-migration gotcha in CLAUDE.md Tests - 5-case residential smoke spec - Integration test updates for new service signatures Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 21:54:32 +02:00
*/
feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
export function BrandedAuthShell({ children, branding }: BrandedAuthShellProps) {
const logoUrl = branding?.logoUrl || DEFAULT_LOGO_URL;
const altText = branding?.appName || 'Port Nimara';
// fixed inset-0 anchors the auth surface to the viewport directly —
// iOS Safari ignores overflow-hidden on inner divs for body-level
// scrolling, so a regular `h-[100dvh] overflow-hidden` wrapper doesn't
// stop the rubber-band bounce. Pinning to the viewport via position
// fixed does. The fixed-position shell then uses flex to center the
// card within the visible area.
return (
<div className="fixed inset-0 flex items-center justify-center px-4 py-8 overscroll-none">
<div
aria-hidden
className="absolute inset-0 -z-10"
style={{
feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
backgroundImage: `url('${DEFAULT_BG_URL}')`,
backgroundSize: 'cover',
backgroundPosition: 'center',
backgroundColor: '#f2f2f2',
}}
/>
<div className="w-full max-w-md">
<div className="bg-white rounded-lg shadow-lg p-8">
<div className="flex justify-center mb-6">
{/* eslint-disable-next-line @next/next/no-img-element */}
feat(branding): wire per-port branding through every transactional email + auth shell (R2-H15) Multi-tenant branding admin (/admin/branding) was saving 5 settings that no code read — every port's emails shipped Port Nimara's logo and color regardless. Now wired end-to-end: New shared infrastructure: - src/lib/email/shell.ts — renderShell() + brandingPrimaryColor() helpers; takes BrandingShell { logoUrl, primaryColor, emailHeaderHtml, emailFooterHtml }, falls back to Port Nimara defaults when null. - src/lib/email/branding-resolver.ts — getBrandingShell(portId) thin wrapper over getPortBrandingConfig() that returns null on error / missing portId so senders never break on misconfig. All 6 transactional templates refactored to use renderShell + the shared accent color; portName now flows through every template (crm-invite, portal activation/reset, both inquiries, both residential templates, notification digest). All 6 senders pass branding via getBrandingShell: - portal-auth.service.ts (activation + reset) - crm-invite.service.ts (resend path; create-invite has no portId yet so falls through to defaults) - email worker (inquiry confirmation + sales notification) - residential-inquiries route (client confirmation + sales alert) - notification-digest.service.ts (digest) BrandedAuthShell takes an optional `branding` prop with logoUrl + appName (parent page server-fetches via getPortBrandingConfig). Defaults to Port Nimara if omitted, so single-tenant deployments are unaffected. 1175/1175 vitest passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 00:00:45 +02:00
<img src={logoUrl} alt={altText} className="w-24 h-auto" />
</div>
{children}
</div>
</div>
</div>
);
}