bb855d2ddc
* feat(branding): implement dynamic branding in service worker and reports * feat(auth): enhance API key scopes and add bookkeeping write scope - Updated transaction write scope description to include additional tools. - Enhanced reports read scope description to reflect new functionality. - Introduced bookkeeping write scope with relevant description. - Updated SCOPE_GROUPS to include bookkeeping domain. - Modified TOOL_SCOPE_MAP to include new bookkeeping operations. - Updated validateApiKey function to return api_key_id and api_key_name for better actor attribution. feat(tests): add unit tests for MCP resource registry - Created tests for data resources to ensure all required fields are present. - Added tests for resource query parsing and retrieval. feat(resources): implement MCP resources for company and accounting data - Added capabilities resource to expose API key capabilities based on granted scopes. - Implemented chart of accounts resource to retrieve active BAS chart. - Created company current resource to fetch active company details. - Developed active fiscal period resource to check posting eligibility. - Implemented recent activity resource to fetch latest journal entries, invoices, and transactions. - Added VAT treatments resource to provide available VAT rates per customer type. feat(pending-operations): introduce risk tiers for operations - Added risk level classification for pending operations to determine auto-commit eligibility. - Implemented functions to classify operation risk levels and identify high-risk operations. feat(migrations): add actor model and risk tier to pending operations - Updated pending_operations table to include actor type and risk level columns. - Enhanced audit_log to mirror actor information for compliance. - Modified validate_and_increment_api_key function to return actor details. - Expanded operation types in pending_operations to include new high-risk operations. * feat: add auto-commit functionality for low-risk pending operations - Implemented shouldAutoCommit function to determine eligibility for auto-commit based on operation type, actor type, and company settings. - Created commitPendingOperation function to handle execution of pending operations with consistent status updates. - Added tests for shouldAutoCommit to cover various scenarios including high-risk operations, user actors, company opt-in status, and monetary thresholds. - Introduced new columns in company_settings for agent_auto_commit_enabled and agent_auto_commit_max_amount to allow companies to opt-in for auto-commit functionality. - Added SQL migration to update the database schema for new auto-commit settings. * feat(idempotency): implement idempotency key handling for safe retries and cleanup * feat: expand API key scopes and pending operations for bookkeeping - Added 'suppliers:write' scope to API key scopes for supplier invoice management. - Updated SCOPE_GROUPS to include the new 'suppliers:write' scope. - Introduced new pending operation types for bookkeeping: close_period, lock_period, run_year_end, set_opening_balances, run_currency_revaluation, explain_voucher_gap, uncategorize_transaction, approve_supplier_invoice, credit_supplier_invoice, and convert_invoice. - Implemented corresponding commit functions for the new operations in the pending operations module. - Enhanced PendingOperation type to include actor model and risk level attributes. - Added tests for new functionality, ensuring proper behavior and constraints in the database. * feat: implement unlockPeriod functionality and related tests * feat: add agent auto-commit settings and related functionality * feat: add attention resource with comprehensive summary of outstanding tasks * feat: enhance pending operations with 'committing' status and immutability checks, improve idempotency handling, and add original voucher reference for credit notes
52 lines
2.4 KiB
SQL
52 lines
2.4 KiB
SQL
-- Migration: idempotency_keys table for safe agent retries.
|
|
--
|
|
-- Why this exists: agent-driven write operations (MCP tools, automation
|
|
-- webhooks) must be safe to retry — agents transparently re-call on
|
|
-- network blips, timeouts, or LLM-mediated retry loops. Without an
|
|
-- idempotency layer, retrying a `create_invoice` after a network blip can
|
|
-- create two invoices and double-book the revenue.
|
|
--
|
|
-- Lifecycle:
|
|
-- 1. Caller sends an `idempotency_key` (random nonce per logical operation)
|
|
-- 2. Server consults this table; on hit, returns the cached response
|
|
-- 3. On miss, server proceeds normally and stores the response
|
|
-- 4. Cleanup cron deletes rows older than 24h
|
|
--
|
|
-- The (user_id, key) pair is unique — a key is scoped to one user so an
|
|
-- agent in account A cannot collide with account B even if they reuse the
|
|
-- same UUID.
|
|
--
|
|
-- request_hash: SHA-256 of the canonical request body. Lets us detect
|
|
-- "same key, different payload" misuse and return 409 Conflict instead of
|
|
-- silently returning the cached response for a different request.
|
|
|
|
CREATE TABLE public.idempotency_keys (
|
|
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
|
|
user_id UUID NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
|
|
company_id UUID REFERENCES companies(id) ON DELETE CASCADE,
|
|
key TEXT NOT NULL,
|
|
request_hash TEXT NOT NULL,
|
|
scope TEXT NOT NULL DEFAULT 'mcp_tool', -- 'mcp_tool' | 'api_route' | future
|
|
response_status TEXT NOT NULL CHECK (response_status IN ('success', 'error')),
|
|
response_body JSONB NOT NULL DEFAULT '{}',
|
|
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
|
expires_at TIMESTAMPTZ NOT NULL DEFAULT now() + interval '24 hours'
|
|
);
|
|
|
|
-- Unique key per user — same key in different accounts cannot collide.
|
|
CREATE UNIQUE INDEX idx_idempotency_keys_user_key
|
|
ON public.idempotency_keys (user_id, key);
|
|
|
|
-- TTL index supports cleanup cron (delete where expires_at < now()).
|
|
CREATE INDEX idx_idempotency_keys_expires
|
|
ON public.idempotency_keys (expires_at);
|
|
|
|
ALTER TABLE public.idempotency_keys ENABLE ROW LEVEL SECURITY;
|
|
|
|
-- Service role writes; users can read their own rows for debugging.
|
|
CREATE POLICY "idempotency_keys_select_own" ON public.idempotency_keys
|
|
FOR SELECT USING (auth.uid() = user_id);
|
|
-- No INSERT/UPDATE/DELETE policies — writes via service role only.
|
|
|
|
NOTIFY pgrst, 'reload schema';
|