Edit Contact Information with Validation
The edit contact screen must provide a form-based interface for updating contact information with real-time field validation. The form must enforce required fields, validate phone number formats, and prevent saving with invalid data. Changes must be persisted to the Supabase backend via the contact edit service and immediately reflected in the contact detail screen. The form must respect the same RLS policies to prevent coordinators from editing contacts outside their chapter scope.
User Story
Audience Summaries
Empowering coordinators to self-serve contact edits directly addresses a critical operational bottleneck in the peer mentor matching workflow. When contact information becomes stale—wrong phone numbers, outdated assignments—failed outreach attempts accumulate, eroding coordinator confidence and ultimately reducing the quality of peer mentor placements.
By enabling real-time editing with built-in validation and RLS-enforced chapter scoping, the organization eliminates the admin escalation overhead while maintaining strict data governance. This directly improves coordinator satisfaction, reduces time-to-contact for program participants, and strengthens HLF's ability to scale chapter operations without proportionally increasing central admin headcount. The competitive advantage lies in a system that is simultaneously permissive enough for efficient operations and secure enough to prevent cross-chapter data leakage.
This is a high-priority story with moderate delivery complexity spanning UI form design, client-side validation logic, backend persistence via the contact edit service, and Supabase RLS policy enforcement. The five acceptance criteria map directly to testable scenarios: pre-population on open, inline validation on required fields, successful round-trip persistence, RLS rejection for out-of-scope contacts, and unsaved-changes confirmation on back navigation. Dependencies on story-contact-list-management-coordinator-003 must be resolved before development begins, as the edit screen is reached from the contact list flow. UAT should include coordinators from at least two chapters to validate RLS scoping behavior in realistic multi-tenant conditions.
Risk: edge cases around concurrent edits or connectivity loss during save need explicit handling to avoid silent data loss.
Implementation requires a form-based screen with controlled inputs for all contact fields, real-time validation hooks enforcing required-field presence and phone number format (regex or a validation library). The save button must be reactively disabled whenever validation state is invalid. On submit, the contact edit service issues an authenticated PATCH/PUT to the Supabase REST or PostgREST endpoint; the RLS policy on the contacts table must already be configured to restrict writes to rows within the coordinator's chapter scope—this must be verified in integration tests, not just unit tests. On success, navigate back and trigger a detail screen refresh (cache invalidation or refetch).
On RLS rejection (403/permission denied), surface a user-friendly error without exposing policy internals. The unsaved-changes guard requires tracking dirty state and intercepting the back navigation event. Edge cases: network timeout during save, partial field updates, and concurrent edit conflicts.
Acceptance Criteria
- Given I am on the contact detail screen, when I tap the edit button, then the edit contact screen opens pre-populated with the contact's current information
- Given I am editing a contact, when I clear a required field and attempt to save, then I see an inline validation error message and the save button is disabled
- Given I submit valid edits, when the save operation completes successfully, then I am returned to the contact detail screen which immediately shows the updated information
- Given I am editing a contact outside my chapter scope, when the save operation is attempted, then the RLS policy blocks the write and I see an appropriate error message
- Given I am editing a contact and close the screen without saving, when a navigation back action is triggered, then I am prompted to confirm discarding unsaved changes
Business Value
Keeping contact information current is fundamental to the peer mentor matching process. If coordinators must escalate every data change to a central admin, incorrect phone numbers and outdated assignments persist longer, leading to failed contact attempts and wasted coordination effort. Self-service editing with proper RLS guards balances operational efficiency with data security.
Components
- Edit Contact Screen ui
- Contact Edit Service service
- Contact Detail Repository data
- Contact Form Validator infrastructure
- Contact RLS Query Builder infrastructure