@pylonsync/create-pylon 0.3.328 → 0.3.329

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pylonsync/create-pylon",
-  "version": "0.3.328",
+  "version": "0.3.329",
   "description": "Scaffold a new Pylon app — realtime backend + web/mobile/expo frontends in one command. Run via `npm create @pylonsync/pylon@latest`.",
   "publishConfig": {
     "access": "public"

package/templates/default/app/dashboard/dashboard-client.tsx

@@ -445,9 +445,10 @@ function IconBtn({
   );
 }
 
-// One project card. Reads/writes live via the reactive `db` — rename, archive,
-// and delete are optimistic and sync across tabs (all gated by the tenant
-// policy). Editing swaps the card for an inline name + description form.
+// One project card. Archive + delete are optimistic client `db` writes (gated
+// by the tenant policy) that sync across tabs; editing details saves through the
+// updateProject server function. Editing swaps the card for an inline name +
+// description form.
 function ProjectCard({ p }: { p: Project }) {
   const archived = (p.status ?? "active") === "archived";
   const [editing, setEditing] = useState(false);
@@ -459,7 +460,12 @@ function ProjectCard({ p }: { p: Project }) {
     const n = name.trim();
     if (!n) return;
     setEditing(false);
-    await db.update("Project", p.id, {
+    // Saving details goes through the updateProject server function (server-side
+    // validation + a workspace-membership re-check) rather than a bare
+    // db.update — see functions/updateProject.ts. The reactive `db` still
+    // re-renders this card the moment the write lands.
+    await callFn("updateProject", {
+      projectId: p.id,
       name: n,
       description: desc.trim() || undefined,
     });

package/templates/default/functions/updateProject.ts

@@ -0,0 +1,53 @@
+import { mutation, v } from "@pylonsync/functions";
+import { normalizeProjectName } from "../lib/projects";
+
+// updateProject — the reference example for a first-party server function, and
+// the core authoring loop end to end: entity → policy → FUNCTION → call it from
+// the client. The Projects tab's edit form (app/dashboard/dashboard-client.tsx)
+// saves through this via `callFn("updateProject", …)`.
+//
+// Why a server function and not a direct client `db.update`? Two reasons the
+// pattern exists:
+//   1. Server-side validation the client can't be trusted to enforce — the name
+//      bounds run on the server no matter what the browser sends.
+//   2. Authorization beyond "owns the row". Functions BYPASS entity policies and
+//      run with full DB access, so a handler that trusted a caller-supplied
+//      `projectId` would be an IDOR. `ctx.requireMember` re-checks that the
+//      caller belongs to THAT project's workspace, failing CLOSED (throws
+//      FORBIDDEN otherwise). Pass `{ role: ["owner", "admin"] }` to make edits
+//      admin-only.
+//
+// Quick archive/delete stay as direct client `db` writes — the Project row
+// policy (`auth.tenantId == data.orgId`) already covers "edit a row you own".
+// Reach for a function when you need more than that.
+export default mutation<
+  { projectId: string; name: string; description?: string },
+  { id: string; name: string }
+>({
+  // `auth` defaults to "user" (secure-by-default) — requireMember does the rest.
+  args: {
+    projectId: v.string(),
+    name: v.string(),
+    description: v.optional(v.string()),
+  },
+  async handler(ctx, args) {
+    const name = normalizeProjectName(args.name);
+    if (!name) {
+      throw ctx.error("INVALID_ARGS", "Project name must be 1–80 characters.");
+    }
+    const description = args.description?.trim() || undefined;
+
+    // Load the target row, then authorize against ITS OWN workspace — never a
+    // caller-supplied org id.
+    const project = await ctx.db.get("Project", args.projectId);
+    if (!project) {
+      throw ctx.error("NOT_FOUND", "Project not found.");
+    }
+    await ctx.requireMember(project.orgId as string);
+
+    // Authorized above, so write through the explicit trusted-handler surface
+    // (also correct under PYLON_STRICT_FN_POLICIES).
+    await ctx.db.unsafe.update("Project", args.projectId, { name, description });
+    return { id: args.projectId, name };
+  },
+});

package/templates/default/lib/projects.ts

@@ -0,0 +1,14 @@
+// Pure project helpers. AGENTS.md's testing guidance: keep the decision logic
+// out of the handler and in a pure function here, so it's exhaustively testable
+// without a running server (see tests/projects.test.ts). functions/updateProject.ts
+// is a thin wrapper around this.
+
+/**
+ * Trim + validate a project name. Returns the cleaned name, or null when it's
+ * empty (or whitespace-only) or longer than 80 characters after trimming.
+ */
+export function normalizeProjectName(raw: string): string | null {
+  const name = raw.trim();
+  if (name.length < 1 || name.length > 80) return null;
+  return name;
+}

package/templates/default/tests/projects.test.ts

@@ -0,0 +1,18 @@
+import { expect, test } from "bun:test";
+import { normalizeProjectName } from "../lib/projects";
+
+// Tier 1 (pure logic) — the validation functions/updateProject.ts enforces
+// server-side, tested without a running app. Keep decision logic like this in
+// lib/ and the handler a thin wrapper, so it's covered here.
+
+test("normalizeProjectName trims and accepts 1–80 chars", () => {
+  expect(normalizeProjectName("  Launch  ")).toBe("Launch");
+  expect(normalizeProjectName("x")).toBe("x");
+  expect(normalizeProjectName("a".repeat(80))).toBe("a".repeat(80));
+});
+
+test("normalizeProjectName rejects empty, whitespace-only, and too-long names", () => {
+  expect(normalizeProjectName("")).toBeNull();
+  expect(normalizeProjectName("   ")).toBeNull();
+  expect(normalizeProjectName("a".repeat(81))).toBeNull();
+});