- Печать доступна только после согласования (Отдел рекрутинга); выбор организации и логотип-шапка для форм с несколькими юрлицами - «СЗ на перемещение ТМЦ»: заявителя можно выбрать (подача за другого), маршрут резолвится на выбранного - «Реферальная рекомендация»: организация вакансии (мультивыбор) и подразделение/проект вакансии - Поле «Подразделение» (справочник) — Vacation, UnpaidLeave, Clearance, WorkplaceSetup, RecruitingHire, RecruitingSelection, TmcTransfer - Поле «Проект» — Vacation, UnpaidLeave, Clearance
Реферальная рекомендация (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) - «Создать на основе»: нет