Hardik
2afdeec6ad
PO/receipt attachments were uploaded via a browser presigned PUT straight to R2 (POST /api/files/sign -> PUT uploadUrl -> linkDocument). That direct browser->R2 PUT only succeeds when the bucket carries a CORS policy allowing PUT from the portal origin; in production that policy was missing, so the browser silently blocked the PUT, linkDocument never ran, and no PODocument row was created -- "documents uploaded but not visible anywhere" (0 PODocument rows in prod/staging). Route uploads through a server action (uploadPoDocuments) that writes the file with uploadBuffer and creates the PODocument row atomically -- the same pattern the crewing module already uses for CV/crew-document uploads, and within the 10mb serverActions.bodySizeLimit. This removes the R2-CORS dependency and guarantees a created row always has its stored file. Removes the now-dead presigned path (lib/upload-files.ts, app/actions/link-document.ts, api/files/sign/route.ts). Adds an integration test that drives the action against a real DB and asserts the PODocument row is created and surfaced by the exact include the PO detail page renders from (i.e. the attachment is visible). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
60 lines
2.4 KiB
TypeScript
60 lines
2.4 KiB
TypeScript
"use server";
|
|
|
|
import { auth } from "@/auth";
|
|
import { db } from "@/lib/db";
|
|
import { buildStorageKey, uploadBuffer } from "@/lib/storage";
|
|
import { revalidatePath } from "next/cache";
|
|
|
|
// Matches the FileUploader hint ("up to 10 MB each") and
|
|
// next.config.ts → experimental.serverActions.bodySizeLimit.
|
|
const MAX_BYTES = 10 * 1024 * 1024;
|
|
|
|
/**
|
|
* Persist PO attachments **server-side**: write each file to storage with
|
|
* `uploadBuffer` and create its `PODocument` row in the same step.
|
|
*
|
|
* Replaces the earlier browser-presigned-PUT flow (`POST /api/files/sign` → the
|
|
* browser `PUT`s the file straight to R2 → `linkDocument` creates the row). That
|
|
* direct browser→R2 `PUT` only works if the R2 bucket carries a CORS policy
|
|
* allowing `PUT` from the portal's origin. In production that policy was missing,
|
|
* so the browser silently blocked the upload, `linkDocument` was never reached,
|
|
* and **no `PODocument` row was created** — the "documents uploaded but not
|
|
* visible anywhere" report (0 PODocument rows in prod/staging).
|
|
*
|
|
* Uploading through the server — the same pattern the crewing module already uses
|
|
* for CVs / crew documents (`uploadBuffer`) — removes the CORS dependency and
|
|
* makes the store-and-link atomic, so a created row always has its file.
|
|
*
|
|
* Returns `{ error }` on the first failure, or `null` on success (the contract
|
|
* the PO and receipt forms already expect).
|
|
*/
|
|
export async function uploadPoDocuments(
|
|
poId: string,
|
|
files: File[],
|
|
type: "po-document" | "receipt" = "po-document"
|
|
): Promise<{ error: string } | null> {
|
|
const session = await auth();
|
|
if (!session?.user) return { error: "Unauthorized" };
|
|
|
|
const po = await db.purchaseOrder.findUnique({ where: { id: poId }, select: { id: true } });
|
|
if (!po) return { error: "PO not found" };
|
|
|
|
for (const file of files) {
|
|
if (!(file instanceof File) || file.size === 0) continue;
|
|
if (file.size > MAX_BYTES) {
|
|
return { error: `${file.name} is larger than the 10 MB limit.` };
|
|
}
|
|
|
|
const key = buildStorageKey(type, poId, file.name);
|
|
const mimeType = file.type || "application/octet-stream";
|
|
const buffer = Buffer.from(await file.arrayBuffer());
|
|
|
|
await uploadBuffer(key, buffer, mimeType);
|
|
await db.pODocument.create({
|
|
data: { poId, storageKey: key, fileName: file.name, fileSize: file.size, mimeType },
|
|
});
|
|
}
|
|
|
|
revalidatePath(`/po/${poId}`);
|
|
return null;
|
|
}
|