Build Edit Contact Screen
epic-contact-detail-and-edit-main-screen-task-011 — Implement the edit contact screen that composes multi-chapter-affiliation-chip for NHF chapter management, drives validation through contact-form-validator, and submits via contact-edit-service. The screen must be visible only to coordinators and admins (hidden for read-only roles via permission-checker). Handle GoRouter route contact/:id/edit, inline error display, and save confirmation feedback.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use a `BLoC` or `AsyncNotifier` (Riverpod) to manage form submission state: `idle | submitting | success | error`. Drive the save button enabled/disabled state and loading indicator from this state. Implement dirty-state tracking by comparing the current form field values against the original contact snapshot captured on mount. For the unsaved-changes dialog, use a `PopScope` widget (Flutter 3.16+) with `onPopInvokedWithResult` to intercept back navigation.
GoRouter redirect guard should be implemented in the route's `redirect` callback, not inside the screen widget. Pass `autofocus: true` to the first field with an error after a failed submit to improve keyboard navigation flow.
Testing Requirements
Widget tests (flutter_test): (1) verify screen pre-populates fields from mock contact data; (2) submit with invalid data — verify inline field errors appear and form is not submitted; (3) simulate successful submit — verify `SnackBar` shown and navigator pops; (4) simulate network error — verify error banner appears and form state is preserved; (5) verify save button is disabled during in-progress state; (6) verify unsaved-changes dialog appears on back press when form is dirty; (7) verify read-only role is redirected. Accessibility: use `SemanticsHandle` to confirm all inputs have labels and error messages are announced. Target ≥85% widget test coverage.
The Peer Mentor Profile tab on the contact detail screen depends on the peer-mentor-detail-screen-widget being delivered by the separate Peer Mentor Detail feature. If that feature is delayed, the navigation affordance will be present but lead to a stub screen, which may confuse coordinators in the TestFlight pilot.
Mitigation & Contingency
Mitigation: Implement the peer mentor tab with a feature flag guard. When the Peer Mentor Detail feature is incomplete, the flag disables the tab. Coordinate delivery timelines with the team responsible for Peer Mentor Detail to align TestFlight releases.
Contingency: If the Peer Mentor Detail feature is significantly delayed, ship the contact detail screen without the peer mentor tab in the first TestFlight build and add it as an incremental update once the dependent screen is ready.
The contact detail screen must adapt its layout significantly based on organisation context: NHF shows affiliation chips, Blindeforbundet shows encrypted fields and assignment status, standard contacts show neither. Managing this conditional rendering without introducing bugs in each variant is complex and increases the risk of organisation-specific regressions.
Mitigation & Contingency
Mitigation: Define a ContactDetailViewModel that resolves all org-specific flags (showEncryptedFields, showAssignmentStatus, showMultiChapterChips) from the organisation config before the widget tree renders. Widget tests must cover all three organisation variants as separate test cases to catch regressions.
Contingency: If conditional rendering logic grows unwieldy, refactor into separate composable section widgets (ProfileHeaderSection, AffiliationSection, EncryptedFieldsSection) that are conditionally included by the parent screen, isolating org-specific logic to individual components.