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>
161 lines
6.0 KiB
Markdown
161 lines
6.0 KiB
Markdown
# 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 1–3 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.
|