Duplicate Warning Event Logger
Component Detail
Description
Infrastructure utility that logs duplicate activity warning events including whether the user dismissed or cancelled the submission. Supports Bufdir audit requirements by providing a traceable record of all detected duplicates and coordinator decisions.
duplicate-warning-event-logger
Summaries
This component directly supports the organization's compliance obligations with Bufdir by creating a permanent, auditable record of every duplicate activity detection event and the coordinator's response to it. When a coordinator is shown a duplicate warning and either proceeds anyway or cancels, that decision is logged with full context — who made it, when, and for which contact and chapter. This traceability is essential for demonstrating responsible data governance to funders and oversight bodies, and it protects the organization in the event of questions about data quality or participation reporting. It transforms what could be a hidden system behavior into a transparent, accountable process that supports organizational credibility.
This is a low-complexity infrastructure component with a well-defined, narrow scope, making it a good candidate for early delivery or for a junior developer to own. Its only dependency is the supabase-contact-chapter-adapter, which must be available for writing audit entries to Supabase. The flush() interface suggests it may buffer log entries before writing, so testing should verify that entries are not lost if the app is closed between detection and flush. Deployment considerations include ensuring the Supabase table for audit entries exists and has appropriate RLS policies so coordinators can write but not modify historical records.
The component runs only in the mobile execution context, so no backend deployment work is required. Compliance sign-off from stakeholders on the logged data format is recommended before finalizing the schema.
This infrastructure utility provides four interfaces: logDuplicateDetected, logWarningDismissed, logWarningCancelled, and flush. The first three methods are synchronous fire-and-forget calls that buffer event data in memory; flush() persists buffered entries to Supabase asynchronously and returns a Future
Both verbose and silent logging modes must be supported, likely via a configuration flag injected at construction. The audit table schema should include columns for event_type, match_id, coordinator_id, timestamp, and chapter_id to support compliance queries.
Responsibilities
- Log duplicate detection events with timestamp, contact_id, and chapter context
- Record coordinator decision (dismissed or cancelled) after warning shown
- Write audit entries to Supabase for reporting compliance
- Support verbose and silent logging modes
Interfaces
logDuplicateDetected(DuplicateActivityMatch match)
logWarningDismissed(String matchId, String coordinatorId)
logWarningCancelled(String matchId, String coordinatorId)
flush() → Future<void>
Relationships
Dependencies (1)
Components this component depends on
Related Data Entities (3)
Data entities managed by this component