Export Audit Log Repository
Component Detail
Description
Provides CRUD access to the Bufdir export audit log table in Supabase. Enforces append-only semantics for completed records to maintain an immutable audit trail.
bufdir-export-audit-repository
Summaries
The Export Audit Log Repository is the persistence foundation that makes the platform's compliance audit trail legally defensible. By enforcing append-only semantics on completed export records, it ensures that once a Bufdir submission is logged, that record cannot be altered or deleted — providing organisations and Norse Digital Products with an authoritative, tamper-resistant history of all regulatory reporting activity. This is essential for responding to Bufdir or NHF audits, resolving funding disputes, and demonstrating internal governance to boards and donors. The row-level security model ensures each organisation can only access its own export history, protecting data privacy across the multi-tenant platform and reducing compliance risk under GDPR.
This is a low-complexity backend data component that is a prerequisite for the Export Audit Log Service and must be delivered first in any sprint sequencing. Development work is straightforward CRUD against a Supabase table, but the append-only enforcement logic and row-level security configuration require careful testing. Acceptance criteria should include: newly inserted records are queryable immediately, status and file URL updates succeed only before a record is finalised, org-scoped queries return no cross-tenant data, and date-range filtering performs within acceptable latency on a realistic volume of records. The main delivery risk is the Supabase RLS policy configuration — misconfigured policies are a security vulnerability, so plan for a dedicated security review before deploying to production.
Coordinate the database migration for the audit log table with the overall Bufdir feature release.
This backend data component is a Supabase repository implementing direct table access for the bufdir_export_audit_log data model. The six exposed methods cover the full lifecycle: `insert` creates the initial pending record, `updateStatus` and `updateFileUrl` modify mutable fields during export processing, and the three `find*` methods support history queries. Append-only semantics for completed records should be enforced at the repository level by checking current status before allowing `updateStatus` calls — reject mutations if the record is already in a terminal state (complete or failed). Use Supabase's built-in RLS policies with `auth.uid()` or an organisation claim to scope `findByOrg` and `findByOrgAndPeriod` at the database level rather than filtering in application code, ensuring multi-tenant isolation cannot be bypassed.
`findByOrgAndPeriod` should use a Postgres index on (org_id, created_at) or (org_id, period_start, period_end) to keep historical queries fast. This repository has no application-layer dependencies and can be unit tested with a local Supabase instance or mock Postgres client.
Responsibilities
- Insert new export audit records
- Update mutable fields (status, file URL) before record is finalised
- Query audit records by organisation and date range
- Enforce row-level security so orgs can only see their own export history
Interfaces
insert(BufdirExportAuditRecord record)
updateStatus(String exportId, ExportStatus status)
updateFileUrl(String exportId, String fileUrl)
findByOrg(String orgId)
findByOrgAndPeriod(String orgId, DateRange period)
findById(String exportId)
Relationships
Related Data Entities (4)
Data entities managed by this component