HumMission Frontend

Сопутствующая задача к ТЗ от 24.08.2026. Фронтенд реализован полностью (#6093–#6107) и уже отправляет/читает перечисленные поля. Задача самодостаточна: всё, что нужно бэкенду, описано здесь.

1. Новые поля волонтера¶

/api/volunteers (GET списком, POST, PUT) и волонтер внутри /api/volunteer-applications:

Справочник helpDirections (ключ → подпись, подписи используются в Excel):
NO_SPECIALIZATION, CONSTRUCTION_REPAIR, ROOFING, WELDING, ELECTRICAL, PLUMBING, DRIVER_CAR_B, DRIVER_TRUCK_C, COOKING, MEDICAL_HELP, PSYCHOLOGICAL_HELP, LEGAL_HELP, LOADING_UNLOADING, LOGISTICS, CHILDREN_ELDERLY, MEDIA_VOLUNTEER.
Правило целостности: NO_SPECIALIZATION не может встречаться вместе с любым другим значением (на фронте это гарантировано UI, на бэкенде — желательно валидацией, т.к. есть импорт).

2. Заявка из внешнего контура¶

POST /api/volunteer-applications/outer_perimeter (multipart/form-data) дополнительно получает:

• helpDirections — повторяющееся поле, по одному значению на запись (не строка через запятую)
• personalDataConsent — "true" / "false", согласие на обработку ПД (#6105). Без отметки фронт не даёт отправить заявку; значение стоит сохранять как юридический факт с датой.

3. Проставление подтверждения участия из таблицы (#6099)¶

PATCH /api/volunteers/{id}/participation-confirmation
Тело: { "missionParticipationConfirmed": true | false | null }

Решение на согласование: эндпоинт придуман фронтендом. Если удобнее — можно обойтись существующим PUT /api/volunteers/{id}, тогда правится один вызов в VolunteersIndex.tsx (handleParticipationChange). Отдельный PATCH выбран потому, что оператор меняет статус построчно и слать целого волонтера ради одного поля не хочется.

Фронт применяет изменение оптимистично и откатывает значение в UI при любой ошибке, так что до реализации эндпоинта колонка визуально работает, но не сохраняет.

4. Импорт¶

POST /api/volunteer-missions/{id}/import-volunteers — в объектах массива volunteers теперь приходят helpDirections и missionParticipationConfirmed (см. п.1). Тот же эндпоинт используется импортом со страницы «Волонтеры» (#6101).

5. Nullable даты (#6093, #6094)¶

• VolunteerMission.missionStartDate / missionEndDate — nullable
• VolunteerMissionShift.departureDate / arrivalDate — nullable

Фронт отправляет null при пустом значении и корректно отображает отсутствующие даты.

6. Желательно (не блокирует)¶

GET /api/volunteers — отдавать связанные mission (id, name, missionStartDate, missionEndDate) и shift (id, shiftNumber). Сейчас карточка волонтера при отсутствии этих данных догружает последнюю заявку волонтера отдельным запросом (/api/volunteer-applications?volunteerId=...&size=1&sort=createdAt,desc), а фильтр по миссии на странице «Волонтеры» работает только по тем волонтерам, у кого связь пришла в списке.

Совместимость¶

Все новые поля читаются фронтендом защитно (отсутствующее значение = пусто), поэтому фронт можно выкатывать до бэкенда — ничего не сломается, новые поля просто не будут сохраняться.