🏠 Overview › ✅ Implementation Tasks ›✅ epic-pause-status-notifications-ui-task-001

Define PauseNotificationCard data model

epic-pause-status-notifications-ui-task-001 — Define the Dart data model for the pause notification card, including fields for peer mentor name, effective date, optional reason text, and mentor profile deep-link URL. Ensure the model is immutable and equatable, and integrates cleanly with the existing in-app notification feed item interface.

high priority low complexity frontend pending frontend specialist Tier 0

Acceptance Criteria

`PauseNotificationCardData` class is defined in `lib/features/notifications/models/pause_notification_card_data.dart`
Class implements or extends the existing `NotificationFeedItem` interface/abstract class used by the notification feed
Required fields: `peerMentorName` (String), `effectiveDate` (DateTime), `mentorProfileDeepLinkUrl` (String)
Optional field: `reasonText` (String?) — nullable, no default value
Class is annotated with `@immutable` or uses `const` constructor
Class implements `Equatable` (or overrides `==` and `hashCode`) using all fields
`copyWith` method is present and covers all fields
Named constructor `PauseNotificationCardData.fromJson(Map<String, dynamic> json)` correctly parses ISO-8601 date strings for `effectiveDate`
`toJson()` method serialises all fields; `effectiveDate` is serialised as ISO-8601 string
Class has a `notificationType` getter returning the string constant `'pause_status'` as required by the feed item interface
Unit test file `test/features/notifications/models/pause_notification_card_data_test.dart` has at least: round-trip JSON test, equality test, and copyWith test

Technical Requirements

frameworks
Flutter
Dart
data models
assignment
contact
performance requirements
Model construction and JSON parsing must be synchronous and complete in under 1 ms
security requirements
Model must not store raw personnummer or sensitive health data
`reasonText` field must be treated as user-visible free text — callers are responsible for sanitising before display

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Check whether the project already uses `equatable` or `freezed` for model classes — match the existing convention rather than introducing a new approach. If `freezed` is used project-wide, generate the model with `@freezed` and `@JsonSerializable`. The `notificationType` constant should be defined as a `static const String notificationTypeKey = 'pause_status'` on the class to avoid magic strings in the feed renderer. Keep the model in the `notifications` feature folder, not in a global models folder, to maintain feature-boundary discipline.

Testing Requirements

Unit tests in flutter_test covering: (1) `fromJson` with all fields populated, (2) `fromJson` with optional `reasonText` absent (null), (3) `toJson` round-trip equality, (4) `==` equality for two identical instances, (5) `==` inequality when any field differs, (6) `copyWith` produces a new instance with the specified field changed and all others unchanged. All tests synchronous, no mocking needed.

Component
Pause Status Notification Card
ui low
Epic Risks (2)
medium impact low prob integration

The existing notification feed component may expect a specific notification model shape that does not map cleanly to the pause notification payload structure, requiring either payload transformation or feed refactoring.

Mitigation & Contingency

Mitigation: Review the notification-list-item and notification-model contracts before building the card. Design the pause-notification-card to extend or wrap the existing list item pattern rather than replacing it.

Contingency: If the feed contract is incompatible, implement a lightweight adapter that maps the pause notification payload to the feed's expected model shape, keeping the adapter isolated from the core card widget.

low impact low prob dependency

The app's existing toast/banner infrastructure may not support the auto-dismiss timeout duration or dismissal animation required for the peer mentor confirmation banner, necessitating a custom implementation that diverges from the design system.

Mitigation & Contingency

Mitigation: Audit the existing banner and toast components (in-app-notification-banner, notification-list-item) for configurable dismiss timeout before starting implementation. Prefer configuration over custom code.

Contingency: If the existing infrastructure cannot be configured, implement the banner as a thin wrapper with a custom auto-dismiss timer while reusing all visual tokens (colours, spacing, typography) from the design system to maintain consistency.

Quick Links
All Tasks Execution Plan