# Communications Frontend Integration

## Purpose

Messages, internal alerts, and dashboard upcoming events follow the frontend three-layer architecture.

```text
View -> Business Logic -> API/Data Access -> Backend
```

## Files

View layer:

- `frontend/src/pages/modules/MessagesPage.tsx`
- `frontend/src/components/internal-alerts/InternalAlertsModule.tsx`
- `frontend/src/components/safety-protocols/SafetyProtocolsModule.tsx`
- `frontend/src/components/frameworks/MoreModules.tsx` as a module export hub
- `frontend/src/components/frameworks/Dashboard.tsx`
- `frontend/src/components/dashboard/DashboardUpcomingEvents.tsx`

Business logic layer:

- `frontend/src/business/communications/hooks.ts`
- `frontend/src/business/communications/selectors.ts`
- `frontend/src/business/dashboard/hooks.ts`

API/data access layer:

- `frontend/src/shared/api/communications.ts`
- `frontend/src/shared/api/directMessages.ts`
- `frontend/src/shared/types/communications.ts`
- `frontend/src/shared/constants/communications.ts`

## Behavior

- The active Messages module uses `GET /api/direct_messages/contacts`, `GET /api/direct_messages/conversations`, `GET /api/direct_messages/thread/:otherUserId?studentId=...`, and `POST /api/direct_messages/send`.
- Contacts are discovered through linked students:
  - Guardians see each linked student's teacher and office manager.
  - Teachers see guardians for students in their class.
  - Office managers see guardians for students on their campus.
- A conversation is separated by `otherUserId + studentId`, so the same two users can have distinct threads for different students.
- Internal alerts load from `GET /api/communications/events`.
- Users with `MANAGE_INTERNAL_COMM` create alerts through `POST /api/communications/events`.
- Alert creators and in-scope `MANAGE_INTERNAL_COMM` managers can edit alerts, delete wrongly-created alerts, or cancel alerts. Cancel creates a new cancellation notification for the same audience; delete removes the original alert without notifying users.
- The Internal Alerts form sends exact audience targets. Platform scope can target system admins, all users, or selected organization leadership. Organization scope can target organization leadership, selected school leadership, or selected campus staff. School scope can target school leadership or selected campus staff. Campus scope can target its own campus staff. Class scope cannot create alerts.
- Alert lists are server-filtered. Platform root shows platform alerts plus tenant-target alerts created by the current platform user; admins see other users' tenant alerts by drilling into that tenant. Parent tenant scopes see descendant-target alerts they created or manage: organizations see their school/campus target alerts, and schools see their campus target alerts. Parent alerts do not cascade down automatically. A campus alert is also visible to class-scope users because class content is read at campus level.
- Dashboard upcoming events read the same backend event data as the internal alerts module through `useDashboardPage`.
- Safety protocols are loaded through the content catalog backend contract and rendered in a focused view module.
- Event display constants live in shared constants.
- Messages, internal alerts, and safety protocols use shared UI primitives for buttons, form controls, and status panels.

## Remaining Related Work

Alert acknowledgments are still local UI state. Add a backend acknowledgment table when acknowledgments must survive reloads or feed compliance reporting.
