mirror of
https://github.com/arsvendg/Stirling-PDF.git
synced 2026-07-16 03:20:46 +02:00
Reece BrowneandGitHub
8dde4262ec
## Summary Adds the **Policies** feature (proprietary, behind the `POLICIES_ENABLED` flag): backend-driven enforcement that runs a fixed tool pipeline on documents, docked in the right tool sidebar alongside Tools. ## Highlights - **Policy catalog** — 5 categories; **Security** is wired (redact PII + sanitize), the others are marked "Coming soon". - **Backend as source of truth** — policies persist via the Policies engine (`/api/v1/policies`), one policy per category, with a local cache + offline fallback. - **Auto-run** — enabled policies run on every uploaded file: dispatch → poll → import outputs into the workspace. - **Security redact config** — PII preset dropdown + custom word/regex entry + advanced options; tool params map to the backend endpoint fields. - **Activity feed** with retry on failures; **file badges** showing which policies ran on a file (sidebar + files page), tinted to the policy colour. - Reuses the **Watched Folders** engine for each policy's backing folder; policy-owned folders are filtered out of the Watched Folders UI. ## Notes - Gated by `POLICIES_ENABLED` (true in proprietary, false in core) — unreachable in the open-source build. - Frontend-only diff; depends on the backend Policies engine and the merged Watched Folders feature.
62 lines
2.1 KiB
TypeScript
62 lines
2.1 KiB
TypeScript
import type { MutableRefObject } from "react";
|
|
import AutomationCreation from "@app/components/tools/automate/AutomationCreation";
|
|
import { AutomationMode } from "@app/types/automation";
|
|
import type { AutomationConfig } from "@app/types/automation";
|
|
import type { ToolRegistry } from "@app/data/toolsTaxonomy";
|
|
import { useToolWorkflow } from "@app/contexts/ToolWorkflowContext";
|
|
|
|
interface PolicyWorkflowStepProps {
|
|
/**
|
|
* The automation to seed/edit. For setup this is a synthetic config carrying
|
|
* the category preset's operations; for edit it's the policy's backing
|
|
* automation.
|
|
*/
|
|
automation: AutomationConfig;
|
|
/** SUGGESTED seeds-then-creates (setup); EDIT updates in place (settings). */
|
|
mode: AutomationMode;
|
|
/** The host (wizard) triggers the builder's save imperatively from its footer. */
|
|
saveTriggerRef: MutableRefObject<(() => void) | null>;
|
|
/**
|
|
* Called with the saved automation once the builder persists it, plus the tool
|
|
* registry (which lives here) so the wizard can map operations to backend
|
|
* endpoint paths without depending on the ToolWorkflow context itself.
|
|
*/
|
|
onComplete: (
|
|
automation: AutomationConfig,
|
|
toolRegistry: Partial<ToolRegistry>,
|
|
) => void;
|
|
/** Called when save is triggered but the workflow isn't in a saveable state. */
|
|
onSaveFailed?: () => void;
|
|
}
|
|
|
|
/**
|
|
* The policy wizard's "Workflow" step: the Watch Folders automation builder
|
|
* ({@link AutomationCreation}) reused to define a policy's tool pipeline. Kept
|
|
* as its own component so the heavy builder + its ToolWorkflow dependency are
|
|
* isolated (and mockable in the rail tests).
|
|
*/
|
|
export function PolicyWorkflowStep({
|
|
automation,
|
|
mode,
|
|
saveTriggerRef,
|
|
onComplete,
|
|
onSaveFailed,
|
|
}: PolicyWorkflowStepProps) {
|
|
const { toolRegistry } = useToolWorkflow();
|
|
return (
|
|
<AutomationCreation
|
|
mode={mode}
|
|
existingAutomation={automation}
|
|
toolRegistry={toolRegistry}
|
|
hideMetadata
|
|
nameOverride={automation.name}
|
|
saveTriggerRef={saveTriggerRef}
|
|
onBack={() => {}}
|
|
onComplete={(saved) => onComplete(saved, toolRegistry)}
|
|
onSaveFailed={onSaveFailed}
|
|
/>
|
|
);
|
|
}
|
|
|
|
export { AutomationMode };
|