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.
|