Bots get list_hooks, pause_hook and delete_hook, which act directly since they only take away. A new hook, or a new name, brief or filter, or switching a paused one back on, goes through propose_hook: it stores a hook_proposals row and puts a [hook-proposal:ID] card in the reply, which the user it was proposed to confirms or rejects. The card is read from what Confirm saves, with the bot's reason labelled as its own; confirming checks everything again and saves through the Hooks modal's helpers. A new hook's URL is shown on the card once, to the user only, never in the outcome the bot is told. What calls a hook, its computers and its signing are never proposed. Only chat replies propose, and a hook call's own run gets no hook tools, so a caller's payload can't reach them. Co-Authored-By: Claude Opus 5.5 <[email protected]>
29 lines
883 B
TypeScript
29 lines
883 B
TypeScript
import BunSQLite from "@moduletrace/bun-sqlite";
|
|
import type { BUN_SQLITE_COBBLE_HOOK_PROPOSALS } from "@/db/types/db";
|
|
import AppError from "@/src/utils/app-error";
|
|
import parseHookProposalRow from "./parse-hook-proposal-row";
|
|
|
|
type Params = {
|
|
proposal_id: number | string;
|
|
/**
|
|
* The user it was proposed to: nobody else reads it.
|
|
*/
|
|
user_id: number | string;
|
|
};
|
|
|
|
/**
|
|
* One hook proposal made to this user, or an `AppError`.
|
|
*/
|
|
export default async function grabHookProposal({ proposal_id, user_id }: Params) {
|
|
const row = (
|
|
await BunSQLite.sql<BUN_SQLITE_COBBLE_HOOK_PROPOSALS>({
|
|
sql: `SELECT * FROM hook_proposals WHERE id = ? AND user_id = ?`,
|
|
values: [proposal_id, user_id],
|
|
})
|
|
).payload?.[0];
|
|
|
|
if (!row) throw new AppError(`That proposal doesn't exist.`);
|
|
|
|
return parseHookProposalRow({ row });
|
|
}
|