dhkatz
58a3e70a63
Phase 3, part 2 (`docs/design.md`, "Next"): file blocks. Moderators block a file network-wide by its sha256, so a removed product can't come back under another name or catalog.
**Blocking**
- A file's page (Console → Blocks → a file) shows whether it's blocked and the products using it, so a moderator sees what a block removes before confirming ("Block and remove 2 products").
- Moderators reach it from a product's files (each has a Block link for them) or by pasting a sha256 into the Blocks tab, which also lists blocked files.
- Blocking a file:
- removes every product with a revision using it. Each removal is audited as `product.remove` with the file, so creators are notified and can appeal it as before.
- puts a `{type: "block", sha256}` change in the changes feed of every catalog hosting it, meaning: delete it whatever uses it. (t5de-catalog doesn't read the feed yet.)
- refuses uploads with it from then on (409 `blocked`). Each attempt is audited as `file.blocked_upload` with the person and catalog, so moderators see who tried.
- Unblocking lets the file in again. The products it removed stay removed until a moderator restores them, one by one.
- Who: `product:remove` hub-wide (moderators and admins). The Blocks tab shows only for them.
**API**: `GET /api/v1/blocks`, and `GET`/`PUT`/`DELETE /api/v1/blocks/:sha256` (`docs/products.md`).
**Migration** `0013_file_blocks`: the `file_block` table, and a GIN index on revisions' file lists, so finding the products using a file doesn't scan every revision.
**Checks**
- 53 API tests pass. The new `blocks.test.ts` covers:
- who may block
- the preview of what a block removes
- removal of every product using the file, across catalogs and creators
- the changes feed, notifications and appeals
- refused uploads and their audit entry
- unblocking, and restoring a removed product afterwards
- Type checks pass.
- On a local hub, through the website's own forms:
- the Block link on a product's files, for moderators only
- the Blocks tab, for moderators only (404 for the creator)
- the file's page, then blocking: the product is gone, its creator notified and offered Appeal
- a re-upload through the catalog API: refused, and audited
- unblocking, then Restore
- Fixed along the way: an empty reason gave a generic "Some of that isn't right"; it now says "Give a reason."
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Phase 3, part 2 (`docs/design.md`, "Next"): file blocks. Moderators block a file network-wide by its sha256, so a removed product can't come back under another name or catalog.
**Blocking**
- A file's page (Console → Blocks → a file) shows whether it's blocked and the products using it, so a moderator sees what a block removes before confirming ("Block and remove 2 products").
- Moderators reach it from a product's files (each has a Block link for them) or by pasting a sha256 into the Blocks tab, which also lists blocked files.
- Blocking a file:
- removes every product with a revision using it. Each removal is audited as `product.remove` with the file, so creators are notified and can appeal it as before.
- puts a `{type: "block", sha256}` change in the changes feed of every catalog hosting it, meaning: delete it whatever uses it. (t5de-catalog doesn't read the feed yet.)
- refuses uploads with it from then on (409 `blocked`). Each attempt is audited as `file.blocked_upload` with the person and catalog, so moderators see who tried.
- Unblocking lets the file in again. The products it removed stay removed until a moderator restores them, one by one.
- Who: `product:remove` hub-wide (moderators and admins). The Blocks tab shows only for them.
**API**: `GET /api/v1/blocks`, and `GET`/`PUT`/`DELETE /api/v1/blocks/:sha256` (`docs/products.md`).
**Migration** `0013_file_blocks`: the `file_block` table, and a GIN index on revisions' file lists, so finding the products using a file doesn't scan every revision.
**Checks**
- 53 API tests pass. The new `blocks.test.ts` covers:
- who may block
- the preview of what a block removes
- removal of every product using the file, across catalogs and creators
- the changes feed, notifications and appeals
- refused uploads and their audit entry
- unblocking, and restoring a removed product afterwards
- Type checks pass.
- On a local hub, through the website's own forms:
- the Block link on a product's files, for moderators only
- the Blocks tab, for moderators only (404 for the creator)
- the file's page, then blocking: the product is gone, its creator notified and offered Appeal
- a re-upload through the catalog API: refused, and audited
- unblocking, then Restore
- Fixed along the way: an empty reason gave a generic "Some of that isn't right"; it now says "Give a reason."
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: dhkatz <[email protected]>
61 lines
2.4 KiB
TypeScript
61 lines
2.4 KiB
TypeScript
import { notFound, redirect } from "next/navigation";
|
|
import { cache } from "react";
|
|
import { NavLink } from "@/components/header-client";
|
|
import { api, getMe, isModerator, unwrap, type ConsoleData, type Person } from "@/lib/api";
|
|
|
|
/** The signed-in moderator, or off to sign in; others get not found (these pages aren't for them). */
|
|
export async function requireModerator(path: string): Promise<Person> {
|
|
const me = await getMe();
|
|
if (!me) redirect(`/signin?next=${encodeURIComponent(path)}`);
|
|
if (!isModerator(me)) notFound();
|
|
return me;
|
|
}
|
|
|
|
/** The console as this person sees it (once per request); undefined if it isn't for them. */
|
|
const loadConsole = cache(async (): Promise<ConsoleData | undefined> => {
|
|
const answer = await api.console.get();
|
|
if (answer.error) return undefined;
|
|
return unwrap(answer);
|
|
});
|
|
|
|
/**
|
|
* The signed-in person and their console, or off to sign in. People who manage nothing get not found: the console
|
|
* is for those controlling a product, catalog or room.
|
|
*/
|
|
export async function requireConsole(path: string): Promise<{ me: Person; console: ConsoleData }> {
|
|
const me = await getMe();
|
|
if (!me) redirect(`/signin?next=${encodeURIComponent(path)}`);
|
|
const data = await loadConsole();
|
|
if (!data) notFound();
|
|
return { me, console: data };
|
|
}
|
|
|
|
type Section = ConsoleData["sections"][number];
|
|
|
|
// Settings are on the overview.
|
|
const tabs: { section: Section; href: string; label: string }[] = [
|
|
{ section: "overview", href: "/console", label: "Overview" },
|
|
{ section: "products", href: "/console/products", label: "Products" },
|
|
{ section: "catalogs", href: "/console/catalogs", label: "Catalogs" },
|
|
{ section: "cases", href: "/console/cases", label: "Cases" },
|
|
{ section: "people", href: "/console/people", label: "People" },
|
|
{ section: "blocks", href: "/console/blocks", label: "Blocks" },
|
|
{ section: "audit", href: "/console/audit", label: "Audit" },
|
|
];
|
|
|
|
/** The console's sections this person may see. */
|
|
export async function ConsoleNav() {
|
|
const sections = new Set<Section>((await loadConsole())?.sections ?? ["overview"]);
|
|
return (
|
|
<nav className="mb-8 flex gap-1 border-b pb-3 text-sm">
|
|
{tabs
|
|
.filter((t) => sections.has(t.section))
|
|
.map((t) => (
|
|
<NavLink key={t.section} href={t.href} exact={t.section === "overview"}>
|
|
{t.label}
|
|
</NavLink>
|
|
))}
|
|
</nav>
|
|
);
|
|
}
|