request-portal/src/webparts/requestPortal/forms/Referral

Реферальная рекомендация (recruiting-referral)

Назначение: сотрудник рекомендует внешнего кандидата на открытую вакансию (реферальная программа). Категория: Отдел рекрутинга Списки SP: «Реферальная рекомендация — данные» / «Реферальная рекомендация — согласование» RequestTypeId (внешний API маршрутов): плейсхолдер — получит числовой id при заведении типа в админке approval-route (форма резолвит его в рантайме по pageUrl, хардкодить не нужно — см. docs/forms.md).

Маршрут

• Тип заявки в approval-route API (/api/request-types): pageUrl «recruiting-referral».
• Фазы: согласование + исполнение. Исполнитель в маршруте — фиксированная роль (не выбирается заявителем), которая назначает реального исполнителя через переназначение (флаг AllowReassignToOtherApprovers на шаге в админке approval-route) — см. обсуждение в истории репо. Обе фазы подгружаются отдельными запросами getPlannedMatrix(..., 'Approval' | 'Execution') и рендерятся как два отдельных блока <ApprovalMatrix> (как в RecruitingHire).
• Матрица согласования редактируема заявителем при новой заявке / черновике / возврате: useMatrixEditor(editable = !readOnly). Матрица исполнения — только чтение (фиксируется маршрутом, не заявителем).

Особое поведение

• Кандидат — не сотрудник компании. Его Ф.И.О., телефон, email и город — обычные текстовые поля, а НЕ People-picker: в каталоге тенанта его ещё нет. People-поле здесь только одно — Referrer (рекомендатель).
• Маршрут резолвится по рекомендателю (getPlannedMatrix(..., data.Referrer, ...)), reloadKey матрицы включает data.Referrer. Рекомендацию согласуют по линии рекомендателя — кандидата в тенанте нет, резолвить условия по нему нечем.
• Автоподстановка при создании: рекомендатель = текущий пользователь, его должность и подразделение — из профиля SharePoint (SPS-JobTitle/SPS-Department через approval.getProfileFields), дата подачи = сегодня. При выборе другого рекомендателя должность и подразделение подтягиваются заново — оба поля остаются редактируемыми (фолбэк, если профиль не синхронизирован или подразделение указано не так, как нужно для этой рекомендации). «Подразделение / Объект» вакансии (VacancyDepartment) — отдельное поле, свободный текст: это подразделение, КУДА рекомендуют, а не рекомендателя.
• Условное поле: «Откуда знаете» = «Другое» → появляется обязательное уточнение AcquaintanceSourceOther. При смене варианта уточнение очищается, и в список пишется null (см. buildItem в submit.ts).
• Маски: PhoneInput на ReferrerPhone и CandidatePhone.
• Заголовок элемента (Title): Реферальная рекомендация — {ФИО кандидата} — {вакансия} — дд.мм.гггг.

Секции формы

ReferrerSection (дата подачи · рекомендатель · должность · подразделение · телефон) · CandidateSection (Ф.И.О. · телефон · email · город) · VacancySection (название вакансии · подразделение) · CandidateInfoSection (текущая работа · должность · стаж · как давно знаете · откуда знаете [+ уточнение]) · AssessmentSection (сильные стороны · о чём стоит знать · вахта · ожидания по ЗП)

Точки входа

• rptype: recruiting-referral
• Режим согласующего (просмотр): есть (ReferralView)
• «Создать на основе»: нет