feat: cases (reports, reviews, requests, appeals) and notifications (#9)

Phase 3, part 1 (`docs/design.md`, "Next"): cases and notifications. File blocks, API tokens and two-factor sign-in come as separate PRs. **Cases** - One queue (Console → Cases) for everything someone has to decide. Each case has: - a thread of notes, where internal notes are visible only to those deciding - an assignee (moderators assign cases to moderators) - a decision, Resolve or Decline, with a written resolution that the person who opened it sees - **Reports:** anyone signed in can report a product or catalog from its page (the API also takes rooms and people). - Limits: 10 an hour, one open report per person and thing, and you can't report yourself. - Reports about a product go to the teams of the catalogs hosting it, as well as to moderators. - Only the reporter and moderators know who reported. The audit entry for a report isn't tagged with what it's about, so a product's creator can't find out from their audit log either. - **Rating reviews:** a creator lowering a rating from adult to general now opens a review instead of being refused. The rest of the edit still saves. Resolving the review lowers the rating, recorded in the product's history. - **Removal requests:** a catalog's team can ask moderators to remove a product it hosts, everywhere. Resolving it removes the product. - **Deletion requests:** a catalog's owner asks for deletion from the catalog's console page, and a moderator decides, as agreed. Resolving it marks the catalog `deleted`: its key stops working, nothing is available from it, and its changes feed says so. - **Appeals:** - From the audit log, the person an action affected can appeal it, once: their product removed, delisted or edited by someone else; their catalog suspended or rejected; a ban from a catalog or a declined request to join. - Another moderator decides. An admin may decide an appeal of their own action, and the audit log flags it. - Resolving records the decision; the moderator then undoes the action where it's done. For that, there's now a Restore for removed products (Console → Products, for moderators); the design mentioned one, but it was never built. - The console shows a "Cases" tab, and a to-do with the number of open cases the person could decide. **Notifications** - A bell in the header with the unread count, and a notifications page with "Mark all as read". - Each is also sent to the person's proxies over the realtime connection (`{"type": "notification"}`), so the client can show them later. - They cover: - a moderator edited or locked your product, or undid a change (with the reason) - your product was removed or restored - your case was decided - someone replied on your case - a catalog decided your membership **Also changed** - A product's creator and moderators can now see it when it's adult, even without an adult account. Before, a creator who made their own product adult couldn't open its page any more, and neither could moderators. Getting and wearing adult products still need an adult account. **Not done yet** (in `docs/console.md`): email notifications (the hub sends no email yet), canned reasons, private moderator notes on people and products, and second approval for the most destructive actions. **Migration** `0012_cases`: the `moderation_case`, `case_note` and `notification` tables. (`case` is a reserved word in SQL, hence the table's name.) **Checks** - 51 API tests pass. The 7 in the new `cases.test.ts` cover: - who sees and decides each kind of case, and that the reporter stays private - rate limits and duplicate reports - the thread and internal notes, and assigning - what deciding each kind of case does - appeals by the person affected only, decided by another moderator - restoring a removed product - the notifications - Type checks pass. - On a local hub I went through every flow with the website's own forms: report from a product page; the catalog owner's note and decision; assigning, an internal note and a decision as admin; removal by a moderator, the creator's appeal from the audit log, the admin's decision and Restore; a creator's rating review and the decision lowering the rating; a deletion request and its decline; the notifications, the bell's count, and Mark all as read. - Fixed along the way: - The catalog's team could see who reported. - A missing Resolve/Decline choice was treated as Decline; now it's refused. - The Unassign button sent the typed name instead of nothing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Phase 3, part 1 (`docs/design.md`, "Next"): cases and notifications. File blocks, API tokens and two-factor sign-in come as separate PRs. **Cases** - One queue (Console → Cases) for everything someone has to decide. Each case has: - a thread of notes, where internal notes are visible only to those deciding - an assignee (moderators assign cases to moderators) - a decision, Resolve or Decline, with a written resolution that the person who opened it sees - **Reports:** anyone signed in can report a product or catalog from its page (the API also takes rooms and people). - Limits: 10 an hour, one open report per person and thing, and you can't report yourself. - Reports about a product go to the teams of the catalogs hosting it, as well as to moderators. - Only the reporter and moderators know who reported. The audit entry for a report isn't tagged with what it's about, so a product's creator can't find out from their audit log either. - **Rating reviews:** a creator lowering a rating from adult to general now opens a review instead of being refused. The rest of the edit still saves. Resolving the review lowers the rating, recorded in the product's history. - **Removal requests:** a catalog's team can ask moderators to remove a product it hosts, everywhere. Resolving it removes the product. - **Deletion requests:** a catalog's owner asks for deletion from the catalog's console page, and a moderator decides, as agreed. Resolving it marks the catalog `deleted`: its key stops working, nothing is available from it, and its changes feed says so. - **Appeals:** - From the audit log, the person an action affected can appeal it, once: their product removed, delisted or edited by someone else; their catalog suspended or rejected; a ban from a catalog or a declined request to join. - Another moderator decides. An admin may decide an appeal of their own action, and the audit log flags it. - Resolving records the decision; the moderator then undoes the action where it's done. For that, there's now a Restore for removed products (Console → Products, for moderators); the design mentioned one, but it was never built. - The console shows a "Cases" tab, and a to-do with the number of open cases the person could decide. **Notifications** - A bell in the header with the unread count, and a notifications page with "Mark all as read". - Each is also sent to the person's proxies over the realtime connection (`{"type": "notification"}`), so the client can show them later. - They cover: - a moderator edited or locked your product, or undid a change (with the reason) - your product was removed or restored - your case was decided - someone replied on your case - a catalog decided your membership **Also changed** - A product's creator and moderators can now see it when it's adult, even without an adult account. Before, a creator who made their own product adult couldn't open its page any more, and neither could moderators. Getting and wearing adult products still need an adult account. **Not done yet** (in `docs/console.md`): email notifications (the hub sends no email yet), canned reasons, private moderator notes on people and products, and second approval for the most destructive actions. **Migration** `0012_cases`: the `moderation_case`, `case_note` and `notification` tables. (`case` is a reserved word in SQL, hence the table's name.) **Checks** - 51 API tests pass. The 7 in the new `cases.test.ts` cover: - who sees and decides each kind of case, and that the reporter stays private - rate limits and duplicate reports - the thread and internal notes, and assigning - what deciding each kind of case does - appeals by the person affected only, decided by another moderator - restoring a removed product - the notifications - Type checks pass. - On a local hub I went through every flow with the website's own forms: report from a product page; the catalog owner's note and decision; assigning, an internal note and a decision as admin; removal by a moderator, the creator's appeal from the audit log, the admin's decision and Restore; a creator's rating review and the decision lowering the rating; a deletion request and its decline; the notifications, the bell's count, and Mark all as read. - Fixed along the way: - The catalog's team could see who reported. - A missing Resolve/Decline choice was treated as Decline; now it's refused. - The Unassign button sent the typed name instead of nothing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: dhkatz <[email protected]>
2026-11-05 22:14:08 +00:00
1 parent e07a6c6dac
commit 7299e10b08
@@ -0,0 +1,117 @@
+import type { Metadata } from "next";
+import Link from "next/link";
+import { redirect } from "next/navigation";
+import { caseKinds } from "@/components/cases";
+import { ActionForm, SubmitButton } from "@/components/forms";
+import { PageHeader } from "@/components/status";
+import { DateTime } from "@/components/time";
+import { buttonVariants } from "@/components/ui/button";
+import { Card, CardContent } from "@/components/ui/card";
+import { api, getMe, unwrap, type NotificationEntry } from "@/lib/api";
+import { cn } from "@/lib/utils";
+import { markAllRead } from "../console/cases/actions";
+
+export const metadata: Metadata = { title: "Notifications" };
+
+export default async function Notifications({ searchParams }: { searchParams: Promise<{ before?: string | string[] }> }) {
+  const me = await getMe();
+  if (!me) redirect("/signin?next=/notifications");
+  const raw = (await searchParams).before;
+  const before = typeof raw === "string" && /^\d+$/.test(raw) ? Number(raw) : undefined;
+  const data = unwrap(await api.notifications.get({ query: before ? { before } : {} }));
+
+  return (
+    <>
+      <div className="flex flex-wrap items-start justify-between gap-4">
+        <PageHeader title="Notifications">
+          {data.unread > 0 ? `${data.unread} unread.` : "You're up to date."}
+        </PageHeader>
+        {data.unread > 0 && (
+          <ActionForm action={markAllRead}>
+            <SubmitButton variant="outline" pendingLabel="Marking…">
+              Mark all as read
+            </SubmitButton>
+          </ActionForm>
+        )}
+      </div>
+      <Card>
+        <CardContent>
+          {data.notifications.length === 0 ? (
+            <p className="text-sm text-muted-foreground">Nothing yet.</p>
+          ) : (
+            <ul className="divide-y">
+              {data.notifications.map((n) => {
+                const { text, href } = describe(n);
+                return (
+                  <li key={n.id} className={cn("flex flex-wrap items-baseline gap-x-3 gap-y-1 py-3 first:pt-0 last:pb-0", n.read && "text-muted-foreground")}>
+                    {!n.read && <span className="size-2 shrink-0 self-center rounded-full bg-foreground" aria-label="Unread" />}
+                    <span className="min-w-0 flex-1 text-sm">
+                      {href ? (
+                        <Link href={href} className="underline-offset-4 hover:underline">
+                          {text}
+                        </Link>
+                      ) : (
+                        text
+                      )}
+                    </span>
+                    <span className="text-xs text-muted-foreground">
+                      <DateTime iso={n.at} />
+                    </span>
+                  </li>
+                );
+              })}
+            </ul>
+          )}
+        </CardContent>
+      </Card>
+      {data.before && (
+        <div className="mt-4">
+          <Link href={`/notifications?before=${data.before}`} className={buttonVariants({ variant: "outline" })}>
+            Older
+          </Link>
+        </div>
+      )}
+    </>
+  );
+}
+
+/** A notification in words, and where it leads. */
+function describe(n: NotificationEntry): { text: string; href?: string } {
+  const d = n.data as Record<string, unknown>;
+  const s = (k: string) => (typeof d[k] === "string" ? (d[k] as string) : "");
+  const why = s("reason") ? `: “${s("reason")}”` : "";
+  switch (n.type) {
+    case "product_edited": {
+      const what =
+        s("kind") === "lock"
+          ? "changed the locks on"
+          : s("kind") === "revert"
+            ? "undid a change to"
+            : `changed the ${(d.fields as string[] | undefined)?.join(", ") ?? "info"} of`;
+      return { text: `${s("by") || "A moderator"} ${what} ${s("name")}${why}`, href: `/products/${s("product")}/edit` };
+    }
+    case "product_removed":
+      return { text: `Moderation removed ${s("name")}${why}. You can appeal it from your audit log.`, href: `/console/audit?product=${s("product")}` };
+    case "product_restored":
+      return { text: `Moderation restored ${s("name")}${why}`, href: `/products/${s("product")}` };
+    case "case_decided": {
+      const status = s("status") === "resolved" ? "resolved" : "declined";
+      const res = s("resolution") ? `: “${s("resolution")}”` : "";
+      return { text: `Your ${caseKinds[s("kind")]?.toLowerCase() ?? "case"} was ${status}${res}`, href: `/console/cases/${d.case}` };
+    }
+    case "case_note":
+      return { text: `${s("by") || "Someone"} replied on your ${caseKinds[s("kind")]?.toLowerCase() ?? "case"}`, href: `/console/cases/${d.case}` };
+    case "membership_decided": {
+      const status = s("status");
+      const text =
+        status === "member"
+          ? `You're a member of ${s("name")}`
+          : status === "banned"
+            ? `${s("name")} banned you`
+            : `${s("name")} declined your request to join`;
+      return { text, href: `/catalogs/${s("catalog")}` };
+    }
+    default:
+      return { text: n.type };
+  }
+}