Files
pn-new-crm/src/app/api/v1/admin/documenso/templates/route.ts

31 lines
1.0 KiB
TypeScript
Raw Normal View History

feat(uat-batch): Groups R + T — Documenso list + deferred bugs R62, T64, T65 from the 2026-05-21 plan. U66 deferred with reasoning. Shipped: R62 Documenso-first templates (list endpoint + admin route). New `listTemplates(portId)` in documenso-client paginates through every visible template on the configured instance (5-page cap at 100/page = 500 templates which comfortably covers every observed Documenso deploy). Handles v1 + v2 endpoint shapes; normalises to `{ id, name }` summaries. New `GET /api/v1/admin/documenso/templates` route exposes the list to the admin UI (gated on `admin.manage_settings`). Powers the upcoming admin template picker — the field-mapping editor + sync-now button + per-template badges stay as the picker-UI follow-up. Data path is in place; UI surface lands in a dedicated PR alongside the field-mapping editor. T64 Duplicate E17 + missing partial unique index. Migration 0082 deduplicates any existing (port_id, mooring_number) collisions by archiving all but the canonical row (prefers price-bearing rows, then earliest-created; archived rows carry an explicit `archive_reason` noting the migration). Adds partial unique index `uniq_berths_port_mooring_active` on (port_id, mooring_number) WHERE archived_at IS NULL so archived moorings can be reissued but live duplicates can't be created in the first place. Migration applied to dev DB. T65 Stage-advance gate. `changeInterestStage` now blocks any non-override transition into eoi / reservation / deposit_paid / contract when the primary berth has no price (NULL or 0) — these stages all render the price in templates / merge fields and a $0 generation is a real production gotcha. Override path (sales-manager fix) stays open and records the reason in audit log per the existing override-reason gate. Deferred: U66 EOI bundle UX rework (10-14h) — multi-berth picker inside the EOI generate dialog. Schema (`interest_berths.isInEoiBundle`) and the rendered bundle-range preview row both exist; the remaining work is the picker UI + re-deriving merge tokens per selection state. Best done as a focused session with Documenso-side verification. Verified: tsc clean, vitest 1454/1454, migration applied. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-21 23:52:57 +02:00
import { NextResponse } from 'next/server';
import { withAuth, withPermission } from '@/lib/api/helpers';
import { errorResponse } from '@/lib/errors';
import { listTemplates } from '@/lib/services/documenso-client';
/**
* GET /api/v1/admin/documenso/templates
*
* Lists every Documenso template visible to the configured API key
* for the calling port. Drives the "Documenso-first templates" admin
* picker (R62) reps see real template names instead of having to
* type numeric IDs.
*
* Gated on `admin.manage_settings` since the data exposed is essentially
* the same surface area as the Documenso settings page itself.
*
* Response shape: `{ data: Array<{ id, name }> }`. Cached client-side
* by the picker for ~5 minutes.
*/
export const GET = withAuth(
withPermission('admin', 'manage_settings', async (_req, ctx) => {
try {
const templates = await listTemplates(ctx.portId);
return NextResponse.json({ data: templates });
} catch (error) {
return errorResponse(error);
}
}),
);