Files
pn-new-crm/docs/website-refactor.md
Matt Ciaccio e8d61c91c4
All checks were successful
Build & Push Docker Images / lint (pull_request) Successful in 1m2s
Build & Push Docker Images / build-and-push (pull_request) Has been skipped
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

161 lines
6.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Website → CRM wiring refactor
The `website/` subrepo (Nuxt) currently writes inquiry submissions to NocoDB.
The new CRM exposes its own public ingestion endpoints, so the website needs
to be re-pointed at the CRM and the website's local server-side helpers can
eventually be retired.
This document describes **what needs to change in the website repo**. Nothing
here applies to the CRM repo — that side is already done.
## Endpoints the CRM now exposes
Both are unauthenticated, IP-rate-limited (5/hour), and require an explicit
port id (query param `?portId=…` or header `X-Port-Id`).
| Form intent | New CRM endpoint | Old NocoDB target |
| -------------------- | ---------------------------------------- | ------------------------ |
| Berth interest | `POST /api/public/interests` | `Interests` (NocoDB) |
| Residential interest | `POST /api/public/residential-inquiries` | `Interests (Residences)` |
Notification emails (client confirmation + sales-team alert) are sent by the
CRM itself when these endpoints succeed, so the website's
`sendRegistrationEmails` helper (`server/utils/email.ts`) is no longer
required for these flows.
## Required changes in the website repo
### 1. New env vars
Add to `.env` and the deploy environment:
```
PN_CRM_BASE_URL=https://crm.portnimara.com
PN_CRM_PORT_ID=<uuid of the Port Nimara port row in CRM>
```
`PN_CRM_BASE_URL` defaults to the prod CRM. In dev it can point to the local
tunnel (`shoulder-contain-…trycloudflare.com`) so submissions hit a dev DB.
### 2. Refactor `server/api/register.ts`
Today the file owns both the berth and residence branches and writes to
NocoDB directly. After the refactor, both branches just relay to the CRM:
```ts
const baseUrl = process.env.PN_CRM_BASE_URL;
const portId = process.env.PN_CRM_PORT_ID;
if (category === 'Residences') {
await $fetch(`${baseUrl}/api/public/residential-inquiries?portId=${portId}`, {
method: 'POST',
body: {
firstName: body.first_name,
lastName: body.last_name,
email: body.email,
phone: body.phone,
placeOfResidence: body.address,
preferredContactMethod: body.method_of_contact, // 'email' | 'phone'
notes: body.notes,
// preferences: collect via new optional textarea (see section 4)
},
});
return { success: true };
}
// Berth branch
await $fetch(`${baseUrl}/api/public/interests?portId=${portId}`, {
method: 'POST',
body: {
// map to the CRM's publicInterestSchema (see src/lib/validators/interests.ts)
firstName: body.first_name,
lastName: body.last_name,
email: body.email,
phone: body.phone,
address: body.address,
berthSize: body.berth_size,
berthMinLength: body.berth_min_length,
berthMinWidth: body.berth_min_width,
berthMinDraught: body.berth_min_draught,
yachtName: body.berth_yacht_name,
preferredMethodOfContact: body.method_of_contact,
specificBerthMooring: body.berth, // optional, links interest to a specific berth
},
});
return { success: true };
```
The reCAPTCHA verification stays in the website handler — the CRM trusts the
website to gate its public endpoints.
### 3. Retire dead code
After step 2, the following can be deleted from the website:
- `server/utils/websiteInterests.ts`
- `server/utils/residentialInterests.ts`
- `server/utils/nocodb.ts`
- The NocoDB-specific call sites in `server/utils/email.ts` (the CRM
sends its own confirmation/alert emails)
- NocoDB env vars (`NOCODB_*`)
The Nuxt `/api/berths` route stays as-is — it reads from the
`directus_items.berths` collection for the public site, not the CRM.
### 4. Form additions on `pages/register.vue`
The current residence branch only collects contact info. The CRM accepts an
optional `preferences` field (free-text) and `notes` field. Add a
"Preferences" textarea inside the residences block of
`components/pn/specific/website/register/form.vue`:
```vue
<transition name="fade-down">
<div v-show="interest === 'residences'">
<vee-field
as="textarea"
class="form-input py-3 px-0 md:text-lg border-0 border-t border-davysgrey ..."
placeholder="Tell us what you're looking for (unit type, budget, timeline)"
name="residence_preferences"
:disabled="loading"
/>
</div>
</transition>
```
Append `preferences: body.residence_preferences` in the POST body in
`server/api/register.ts`.
### 5. Stand up a residential-only `residences.vue` form (optional)
Today the residences interest is captured on `register.vue` via a radio. If
the marketing team wants a dedicated CTA on `residences.vue`, add a small
inline form using the same submit handler from step 2. No new endpoint —
this is purely a UX addition.
## Deployment order
1. **CRM first**: deploy this repo, ensure `/api/public/interests` and
`/api/public/residential-inquiries` are reachable from the website host.
2. **Verify in CRM**: configure `Inquiry Contact Email` and (for residential)
`Residential Notification Recipients` per port in
admin → settings.
3. **Smoke test from a dev tunnel** (curl the public endpoints with a JSON
payload). Confirm rows land in `clients`/`residential_clients` and
notification emails are received.
4. **Then deploy website changes** (sections 13 above). The form
submissions immediately start landing in the new CRM.
5. **Cut-over note**: once the website is pointed at the CRM, leave the
NocoDB tables read-only as a historical archive. Don't delete them until
prod data has been imported into the new CRM (see "Prod data import
strategy" task #59 in the task list).
## Open questions
- **Port routing for multi-port deploys**: today the website only knows about
Port Nimara. If/when the website serves multiple ports, the `portId`
resolution needs to happen per-domain or per-route, not a single env var.
- **Brand/email domain**: confirm whether residential confirmations should
send from the same `noreply@letsbe.solutions` address as marina, or a
dedicated residential mailbox. The CRM uses `SMTP_FROM`, which is global.