Receive a Duplicate Activity Warning Before Submitting
Before the final submission, the registration cubit checks the local and remote activity store for a potential duplicate: same activity type, same date, same peer mentor, within a ±15-minute duration window. If a potential duplicate is found, a warning bottom sheet is shown listing the existing similar registration. The peer mentor can choose to proceed with the new registration (with a reason field) or cancel and review the existing entry. NHF specifically flagged cross-coordinator duplicate detection; this story covers self-duplicate detection for the peer mentor.
User Story
Audience Summaries
Duplicate activity registrations directly corrupt the statistical foundation that determines Bufdir grant allocations for NHF. When peer mentors inadvertently submit duplicate records, inflated activity counts lead to incorrect funding calculations and expose NHF to audit risk — a regulatory and reputational liability. By catching duplicates at the point of entry, this story eliminates the most common source of data integrity failures before they propagate into reporting systems. The feature protects grant revenue, reduces costly post-hoc data correction efforts, and demonstrates to Bufdir that NHF operates with rigorous data governance.
NHF leadership specifically flagged this issue, making it a high-visibility item for the organization's relationship with its primary funder. Coordinators also benefit through reduced manual review workload, and the optional reason field creates an auditable override trail that satisfies compliance requirements without blocking legitimate edge-case submissions.
This story has moderate delivery complexity and touches the core activity registration flow, requiring careful coordination between mobile frontend, backend validation, and offline-sync subsystems. The duplicate detection logic must run against both local SQLite state and the remote Supabase store, which introduces a conditional network dependency that must be handled gracefully. The offline fallback path — deferring the check with a local flag until connectivity is restored — requires explicit testing across network transition scenarios. Acceptance criteria define five distinct test cases covering the happy path, the 'submit anyway' override flow, the cancel-and-return path, the offline edge case, and the coordinator-facing duplicate indicator.
UAT should involve coordinators reviewing the duplicate indicator UI, as NHF raised cross-coordinator duplicate concerns separately. Rollout risk is low if the check is implemented as a non-blocking pre-submission gate. Dependency on the base registration story (story-quick-activity-registration-peer-mentor-001) means this should be sequenced in the sprint immediately following that story's completion.
Implementation centers on the registration cubit, which must be extended with a pre-submission duplicate check method. The check queries the local activity store (SQLite via Drift or equivalent) and, if online, also queries the Supabase activities table using a compound filter: same activity_type, same date, same peer_mentor_id, and duration within a ±15-minute window. The result determines whether to emit a DuplicateWarningState or proceed to ConfirmationState. The bottom sheet UI component needs two distinct sub-states: the initial warning listing the conflicting record, and the reason-selector sub-view triggered by 'Submit Anyway'.
Reason codes should be a static enum stored with the submission. Offline detection should use the existing connectivity service; when offline, skip the remote query, proceed to submit, and write a pending_duplicate_check flag to the local record. A background sync job must pick up flagged records and perform the deferred check. On the coordinator side, the activity list query must surface a duplicate_warning boolean, and the list item widget needs a visual indicator.
Ensure the duplicate check is debounced to avoid firing on rapid re-submissions.
Acceptance Criteria
- Given I submit an activity of type 'Phone Call' on today's date for 30 minutes, and I already have a 'Phone Call' registration for today lasting 30 minutes, when I tap Confirm, then the duplicate warning bottom sheet appears before the record is saved
- Given the duplicate warning is shown, when I tap 'Submit Anyway', then a reason selector appears with options (e.g. 'Two separate calls', 'Correcting previous entry') before the submission proceeds
- Given the duplicate warning is shown, when I tap 'Cancel', then the bottom sheet closes and I am returned to the registration form with my data intact
- Given the duplicate check requires a network call and the device is offline, when I submit, then the submission proceeds without a duplicate check and a local flag is set to perform the check when connectivity is restored
- Given I have submitted a registration flagged as a potential duplicate, when the coordinator views the activity list, then both records are marked with a duplicate warning indicator
Business Value
Duplicate registrations directly inflate Bufdir statistics, leading to incorrect grant calculations and potential audit issues. NHF specifically raised this as a concern across coordinators; catching duplicates at the point of entry for the peer mentor is the cheapest place to prevent the problem.
Components
- Registration Confirmation View ui
- Activity Registration Cubit service
- Activity Registration Service service
- Duplicate Warning Bottom Sheet ui
- Duplicate Detection Service service
- Duplicate Check Repository data
- Duplicate Detection BLoC infrastructure
- Duplicate Activity Warning Dialog ui
- Duplicate Activity Detection Service service