Matt
6b28459c45
Replaces the legacy 9-stage pipeline with 7 canonical stages
(enquiry → qualified → eoi → reservation → deposit_paid → contract →
nurturing) plus three doc sub-status columns (eoi_doc_status,
reservation_doc_status, contract_doc_status) that track sent/signed
within a single stage instead of branching it.
Schema (migration 0062):
- interests gains assigned_to, deposit_expected_amount/currency,
three doc-status columns, two documenso-id columns, and
date_reservation_signed.
- New tables: qualification_criteria (per-port admin-configurable),
interest_qualifications (per-interest state), payments (deposit /
balance / refund records keyed to interest + client).
- Default qualification criteria seeded for every existing port.
- Dummy-data UPDATEs collapse Sent/Signed pairs and 'completed' into
the new stage + doc-status + outcome shape.
Migration 0063 adds interest_contact_log.voice_transcript and
template_used columns for v1.1-A/B (quick-template buttons + voice
transcription via Web Speech API).
v1.1 phase work bundled here:
- A/B: Quick-template buttons (Call / Visit / Email) + mic toggle on
the contact-log compose dialog (useVoiceTranscription hook).
- C: berth-rules-engine wraps state writes in pg_advisory_xact_lock
with an idempotent re-read; emits rule_evaluated audit traces.
- D: Documenso webhook: reservation/contract sub-status stamping
moved out of the PDF-download try-block so a download failure
no longer swallows the stamp. New integration test coverage.
- E: /admin/qualification-criteria CRUD page + admin component.
- F: default_new_interest_owner exposed in System Settings.
- G: recentActivityCount + active_engagement deal-pulse signal
surfaced as a chip on interests + hot-deals card.
- H: interest_assigned notification on assignedTo change (skips
self-assign, uses a dedupe key).
Plus the supporting components: AssignedToChip, DealPulseChip,
PaymentsSection, QualificationChecklist, MultiEoiChip,
SkipAheadBanner, WonStatusPanel, InterestBerthStatusBanner,
SupplementalInfoRequestButton, UserPicker.
Tests: 1370/1370 vitest pass (added deal-health unit suite +
expanded constants/validators/pipeline-transitions coverage). tsc
clean, eslint clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
77 lines
2.5 KiB
TypeScript
77 lines
2.5 KiB
TypeScript
'use client';
|
|
|
|
import { useQuery } from '@tanstack/react-query';
|
|
import { AlertTriangle } from 'lucide-react';
|
|
|
|
import { apiFetch } from '@/lib/api/client';
|
|
|
|
interface BerthRow {
|
|
id: string;
|
|
mooringNumber: string;
|
|
status: string;
|
|
isPrimary: boolean;
|
|
}
|
|
|
|
interface BerthsResponse {
|
|
data: BerthRow[];
|
|
}
|
|
|
|
/**
|
|
* Surfaces when one of the interest's linked berths is sold or under offer
|
|
* to a different deal. We don't block the rep from proceeding (the user
|
|
* explicitly wanted v1 to still let the deal advance — the assumption is
|
|
* that the rep is aware and treating the current deal as a fallback if
|
|
* the other one falls through), but the banner makes the conflict visible
|
|
* so they aren't surprised when the rules engine flags it.
|
|
*
|
|
* Fires only for active (non-archived, non-closed) interests — banners on
|
|
* lost deals are noise.
|
|
*/
|
|
export function InterestBerthStatusBanner({
|
|
interestId,
|
|
interestPipelineStage,
|
|
interestOutcome,
|
|
archivedAt,
|
|
}: {
|
|
interestId: string;
|
|
interestPipelineStage: string;
|
|
interestOutcome?: string | null;
|
|
archivedAt?: string | null;
|
|
}) {
|
|
const { data } = useQuery<BerthsResponse>({
|
|
queryKey: ['interest-berths', interestId],
|
|
queryFn: () => apiFetch(`/api/v1/interests/${interestId}/berths`),
|
|
});
|
|
|
|
if (archivedAt || interestOutcome) return null;
|
|
// The banner is most useful before the rep is committed to the deal —
|
|
// once contract is in motion, the conflict is moot.
|
|
if (interestPipelineStage === 'contract') return null;
|
|
|
|
const berths = data?.data ?? [];
|
|
const conflicts = berths.filter((b) => b.status === 'sold' || b.status === 'under_offer');
|
|
if (conflicts.length === 0) return null;
|
|
|
|
return (
|
|
<div
|
|
role="status"
|
|
className="flex items-start gap-2 rounded-md border border-rose-200 bg-rose-50 px-3 py-2 text-xs text-rose-900"
|
|
>
|
|
<AlertTriangle className="size-3.5 mt-0.5 shrink-0" aria-hidden />
|
|
<div>
|
|
<p className="font-medium">
|
|
{conflicts.length === 1
|
|
? `Berth ${conflicts[0]!.mooringNumber} is ${
|
|
conflicts[0]!.status === 'sold' ? 'Sold' : 'Under Offer'
|
|
} to another deal.`
|
|
: `${conflicts.length} linked berths are no longer freely available.`}
|
|
</p>
|
|
<p className="mt-0.5 text-rose-800">
|
|
You can still progress this interest as a backup, but the rep on the other deal owns the
|
|
primary path. If their deal falls through, this one can step in.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
);
|
|
}
|