fix(config): align Configuration pages with platform logic

Audit of the admin Configuration section (FAQ Manager, Notification Rules,
Approval Config) surfaced three contract mismatches and one missing schema.

FAQ
  * Backend `encoach.faq.category.audience` / `encoach.faq.item.audience`
    rejected the `both` and `entity` values emitted by the FAQ Manager
    UI. Widened the Selection so the UI's full vocabulary round-trips.
  * FAQ item `video_url` was already accepted by the UI but silently
    dropped by the controller; now persisted via a new `video_url`
    field on `encoach.faq.item` and serialized on list/get responses.

Notification Rules
  * Added `days_before`, `frequency`, `channel`, `entity_id` to
    `encoach.notification.rule`. These are the exact fields the admin
    form collects; prior to this change they were serialized into the
    JSON body, ignored by the controller, and omitted from responses,
    leaving the Active switch permanently off and the table columns
    blank.
  * Controller now translates `active` <-> `is_active` both ways so the
    new frontend contract and legacy callers coexist. Missing required
    fields return HTTP 400 instead of 500.

Approval Workflows
  * The controller had been hand-rolling raw SQL against three tables
    (`encoach_approval_workflow`, `_stage`, `_request`) that no Odoo
    model declared, so the tables never existed. List() was guarded and
    returned empty; create() would 500 with "relation does not exist".
  * Introduced real ORM models in `encoach_exam_template/models/approval.py`
    plus access rights, which auto-provision the tables on -u.
  * Rewrote the controller to use ORM, added PATCH, and emitted both
    `items` and `results` in the list envelope so the frontend's
    PaginatedResponse reader and legacy callers both work. Step
    payloads now carry `max_days`, `auto_escalate`, and
    `notification_email` end to end.
  * Frontend `approvalsService` and `ApprovalWorkflowConfig` updated to
    send the full stage shape + `allow_bypass`, tolerate both envelope
    keys, and validate at least one approver before submit.

Schema delta applied via `./run.sh -u encoach_exam_template,encoach_lms_api`.
Verified with new `test_config_flows.py`: 24/24 passing. Regression runs
on `test_support_flows.py` (29/29) and `test_training_flows.py` (26/26)
remain green.

Made-with: Cursor

frontend/src/pages/admin/ApprovalWorkflowConfig.tsx

@@ -6,19 +6,12 @@ import { Input } from "@/components/ui/input";
 import { Label } from "@/components/ui/label";
 import { Switch } from "@/components/ui/switch";
 import { Dialog, DialogContent, DialogHeader, DialogTitle, DialogTrigger } from "@/components/ui/dialog";
-import { Plus, Trash2, Loader2, ChevronRight, Settings2, ArrowRight } from "lucide-react";
-import { approvalsService, type ApprovalWorkflow } from "@/services/approvals.service";
+import { Plus, Trash2, Loader2, Settings2, ArrowRight } from "lucide-react";
+import { approvalsService, type ApprovalWorkflow, type ApprovalStage } from "@/services/approvals.service";
 import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";
 import { useToast } from "@/hooks/use-toast";
 
-interface WorkflowStage {
-  order: number;
-  approver_id: number;
-  approver_name: string;
-  max_days?: number;
-  notification_email?: string;
-  auto_escalate?: boolean;
-}
+type WorkflowStage = Omit<ApprovalStage, "order"> & { order: number };
 
 export default function ApprovalWorkflowConfig() {
   const { toast } = useToast();
@@ -28,16 +21,21 @@ export default function ApprovalWorkflowConfig() {
     queryKey: ["approvals", "list"],
     queryFn: () => approvalsService.list(),
   });
-  const workflows = workflowsData?.results ?? [];
+  const workflows: ApprovalWorkflow[] = workflowsData?.results ?? workflowsData?.items ?? [];
+
+  type WorkflowWriteInput = Partial<ApprovalWorkflow> & {
+    steps?: Partial<ApprovalStage>[];
+    bypass_enabled?: boolean;
+  };
 
   const createWorkflow = useMutation({
-    mutationFn: (data: Partial<ApprovalWorkflow>) => approvalsService.create(data),
+    mutationFn: (data: WorkflowWriteInput) => approvalsService.create(data),
     onSuccess: () => qc.invalidateQueries({ queryKey: ["approvals"] }),
     onError: () => toast({ title: "Error", description: "Failed to create workflow", variant: "destructive" }),
   });
 
   const updateWorkflow = useMutation({
-    mutationFn: ({ id, data }: { id: number; data: Partial<ApprovalWorkflow> }) => approvalsService.update(id, data),
+    mutationFn: ({ id, data }: { id: number; data: WorkflowWriteInput }) => approvalsService.update(id, data),
     onSuccess: () => qc.invalidateQueries({ queryKey: ["approvals"] }),
     onError: () => toast({ title: "Error", description: "Failed to update workflow", variant: "destructive" }),
   });
@@ -72,8 +70,26 @@ export default function ApprovalWorkflowConfig() {
   };
 
   const handleCreate = () => {
+    const valid = stages.filter(s => s.approver_id > 0);
+    if (valid.length === 0) {
+      toast({ title: "Validation", description: "Add at least one stage with an approver ID", variant: "destructive" });
+      return;
+    }
     createWorkflow.mutate(
-      { name: wfName, steps: stages.map(s => ({ order: s.order, approver_id: s.approver_id, approver_name: s.approver_name })), status: "draft" } as Partial<ApprovalWorkflow>,
+      {
+        name: wfName,
+        status: "draft",
+        allow_bypass: bypassEnabled,
+        bypass_enabled: bypassEnabled,
+        steps: valid.map(s => ({
+          order: s.order,
+          approver_id: s.approver_id,
+          approver_name: s.approver_name,
+          max_days: s.max_days,
+          auto_escalate: s.auto_escalate,
+          notification_email: s.notification_email,
+        })),
+      },
       { onSuccess: () => { toast({ title: "Workflow Created" }); setShowCreate(false); resetForm(); } },
     );
   };