Gravity Flow Vacation Requests - Плагин WordPress

Руководство по настройке Gravity Flow Vacation Requests для заявок на отпуск в WordPress

Gravity Flow Vacation Requests стоит рассматривать не как отдельную форму "заявка на отпуск", а как расширение к рабочему процессу на базе Gravity Forms и Gravity Flow. В этом руководстве разберём, как подготовить сайт, какие поля и страницы нужны, как настроить маршрут заявки от сотрудника к руководителю и HR, как работает расчёт остатка дней и где чаще всего появляются ошибки.

Материал рассчитан на администратора WordPress, вебмастера или внутреннего специалиста, который уже понимает базовую логику Gravity Forms, но хочет сделать отпускной процесс аккуратным: сотрудник отправляет запрос, руководитель принимает решение, HR видит служебные поля, а пользователь может проверить статус и остаток доступных дней. Вместо рекламного описания ниже будет практическая схема внедрения, проверки и диагностики.

У плагина есть важная особенность: он не заменяет весь Gravity Flow, а добавляет отпускную механику поверх обычных шагов рабочего процесса. Поэтому настройку нужно вести в двух плоскостях: сначала собрать сам рабочий сценарий в Gravity Flow, затем добавить отпускные данные, поле Vacation Days, баланс в профиле пользователя и вывод остатка через shortcode или уведомления.

Какую задачу решает расширение и где оно полезно

Базовый Gravity Flow уже умеет маршрутизировать отправленные формы, назначать шаги пользователям, ролям или email-адресам, показывать входящие задачи, вести статус и отправлять уведомления. Для обычной заявки на согласование этого часто достаточно: сотрудник заполняет форму, руководитель нажимает approve или reject, при необходимости запись возвращается на доработку через шаг User Input, после чего процесс завершается.

Gravity Flow Vacation Requests добавляет то, чего не хватает типовой форме отпуска: учёт доступных дней по конкретному пользователю и автоматическое списание approved vacation days после завершения процесса. Документация расширения описывает отдельное поле Vacation Days, секцию отпускной информации в профиле пользователя, формулу баланса и варианты вывода остатка на странице или в уведомлении.

Практически это полезно для внутренних порталов, корпоративных сайтов, закрытых разделов для сотрудников, экстранетов и небольших HR-процессов, где не хочется заводить отдельную HRM-систему только ради отпускных заявок. Сайт уже хранит пользователей WordPress, Gravity Forms собирает поля заявки, Gravity Flow ведёт согласование, а расширение добавляет слой "сколько дней осталось".

Где расширение даёт максимальную пользу

Лучший сценарий - когда заявка всегда привязана к текущему пользователю WordPress. Тогда система может связать отправителя с его профилем, посчитать доступные дни и показать менеджеру не только даты отпуска, но и контекст: сколько дней запросил сотрудник, сколько у него есть ежегодного отпуска, есть ли перенос или корректировка HR.

• Внутренний портал компании, где сотрудники входят под своими WordPress-аккаунтами.
• Процесс с несколькими ролями: сотрудник, руководитель, HR, администратор портала.
• Заявки, где требуется не только approval, но и служебная обработка после решения менеджера.
• Команды, которым нужно видеть статус запроса без ручной переписки и таблиц.
• Проекты, где отпускные данные достаточно вести внутри WordPress, без синхронизации с отдельной кадровой системой.

Когда лучше не начинать с этого решения

Расширение не стоит выбирать, если нужен полноценный кадровый контур с табелями, payroll, сложными правилами по странам, больничными, заменами по графику, API-интеграцией с ERP и автоматической проверкой конфликтов в календаре. Gravity Flow Vacation Requests помогает вести отпускные заявки внутри WordPress, но не превращает сайт в HRIS.

Есть и продуктовые ограничения, которые нужно принять заранее. Документация указывает, что запросы, пересекающие границу двух лет, нужно разделять на две отдельные заявки. Также заявка начисляет отпуск отправителю формы, а отправка запроса "за другого пользователя" не поддерживается текущей логикой расширения. Эти ограничения критичны для компаний, где HR часто заводит отпуск за сотрудника вручную.

Ключевая проверка перед внедрением: если отпуск должен списываться с баланса текущего пользователя WordPress, расширение подходит. Если HR должен массово оформлять заявки за других людей или вести сложные календарные пересечения, нужно проектировать отдельный процесс или подключать другую систему.

Что должно быть готово перед установкой

Перед установкой важно не начинать с загрузки архива, а описать процесс на бумаге или в документе. Gravity Flow в документации отдельно подчёркивает, что планирование рабочего процесса помогает не держать все шаги в голове. Для отпусков это особенно заметно: одна неверно назначенная роль или поле с неправильной видимостью приводит к тому, что HR-комментарии увидит сотрудник, руководитель не получит задачу, а баланс не будет считаться так, как ожидает компания.

Базовые зависимости

На сайте должны быть установлены и активны WordPress, Gravity Forms, Gravity Flow и само расширение Vacation Requests. Официальная страница продукта указывает как требования актуальные версии Gravity Flow и Gravity Forms. Точные номера лучше проверять в кабинете и документации разработчика перед обновлением, потому что требования могут меняться.

Не описывайте в рабочей инструкции процесс покупки, ввод ключа или обход активации. Для администратора важнее безопасный порядок: сначала резервная копия, затем установка на тестовом сайте, затем проверка формы, ролей, уведомлений и только после этого перенос в рабочий портал.

Роли и права доступа

Gravity Flow использует систему ролей и capabilities WordPress. Для отпускного процесса обычно нужны минимум четыре группы:

• Сотрудники, которые отправляют запрос и смотрят свой статус.
• Руководители, которые видят задачи в Inbox и принимают решение.
• HR или администраторы процесса, которые заполняют служебные поля и корректируют отпускной баланс.
• Технические администраторы, которые могут менять workflow, страницы и настройки.

Отдельно проверьте capability, связанный с редактированием отпускной информации в профиле пользователя. Документация Vacation Requests указывает, что секция отпускной информации редактируется пользователями с capability gravityflowvacation_edit_profiles. Не выдавайте её всем менеджерам автоматически: руководитель может согласовывать заявку, но не всегда должен менять Annual Paid Time Off, Comp Days, HR Adjustment или Carry Over Days.

Форма заявки и поля

Минимальная форма должна содержать имя или автоматическую привязку к пользователю, дату начала, дату окончания, количество запрашиваемых дней, комментарий сотрудника и служебные поля для HR. В расширении ключевым становится поле Vacation Days: если итоговый статус заявки approved, количество дней из этого поля списывается с баланса текущего пользователя.

Для служебных комментариев используйте административные поля Gravity Forms. В обучающих материалах по отпускному сценарию HR-комментарии показываются как administrative field, чтобы обычный submitter не видел внутренние заметки. Это простая, но важная защита от случайной публикации служебной информации.

Страницы для работы с процессом

Для удобного фронтенд-сценария обычно создают три страницы: Inbox, Status и Submit. В каждую добавляют соответствующий Gravity Flow block или shortcode. Документация по блокам предупреждает, что блоки рассчитаны на отдельные страницы и не стоит объединять несколько Gravity Flow blocks на одной странице. Для отпусков это практично: сотрудник отправляет заявку на странице Submit, руководитель работает во Inbox, а сотрудник проверяет прогресс на Status.

Установка и первичная проверка без риска для рабочего сайта

Установка технически похожа на обычный коммерческий WordPress-плагин: архив загружается через Plugins -> Add New -> Upload Plugin, затем активируется. Но для отпускного процесса важнее не сам upload, а порядок проверки. Заявки затрагивают персональные данные сотрудников, внутренние комментарии и управленческие решения, поэтому сначала работайте на staging-копии или закрытом тестовом сайте.

Безопасный порядок первого запуска

1. Сделайте резервную копию сайта и базы данных перед установкой.
2. Проверьте, что Gravity Forms и Gravity Flow активны и обновлены в штатном порядке.
3. Установите и активируйте расширение Vacation Requests.
4. Откройте редактор формы и убедитесь, что доступно поле Vacation Days.
5. Проверьте профиль тестового пользователя: должна появиться секция отпускной информации.
6. Создайте тестовые страницы Inbox, Status и Submit с блоками или shortcode.
7. Исключите эти страницы из серверного кеша, кеш-плагина и оптимизаторов, если они вмешиваются в формы.

На этом этапе ещё рано включать процесс для всех сотрудников. Сначала создайте одного тестового submitter, одного approver и одного HR-пользователя. Так вы увидите, что именно показывается каждой роли, не рискуя открыть служебные поля реальным пользователям.

Быстрая проверка после активации

Откройте Forms -> нужная форма -> редактор полей. Найдите раздел, где Gravity Flow добавляет workflow-поля, и добавьте Vacation Days. Затем перейдите в профиль тестового сотрудника и заполните отпускные значения. Если секция отпускной информации не видна, не начинайте писать workaround в коде: сначала проверьте capability, роль пользователя и активность расширения.

Мини-итог этапа: установка считается успешной не тогда, когда плагин просто активировался, а когда поле Vacation Days доступно в форме, отпускная секция видна ответственному пользователю, а тестовые страницы Workflow открываются без кешированных ошибок.

Настройка формы заявки и отпускного баланса

Самая важная часть настройки - связать поля формы, профиль пользователя и шаги рабочего процесса так, чтобы каждое действие влияло на правильный результат. В типовом сценарии сотрудник вводит даты и количество дней, руководитель видит заявку и остаток, HR при необходимости добавляет служебные заметки, а после завершения workflow approved days участвуют в расчёте баланса.

Поле Vacation Days и логика списания

Документация расширения описывает простую механику: добавьте поле Vacation Days в форму, и если финальный статус approved, значение из этого поля будет вычтено из баланса текущего пользователя. Поэтому это поле нельзя оставлять как декоративную подпись. Оно должно отражать фактическое количество дней, которое компания хочет списать.

Если сотрудник выбирает даты с выходными, праздниками или неполным днём, заранее решите, кто отвечает за число в Vacation Days. В простом процессе сотрудник сам вводит количество рабочих дней. В более контролируемом процессе HR проверяет число на шаге обработки. Не обещайте автоматический календарный расчёт, если он не реализован в вашем конкретном сайте и не подтверждён отдельной интеграцией.

Что проверить в настройках поля

• Поле присутствует в той форме, по которой запускается workflow.
• Поле не скрыто от тех ролей, которые должны видеть запрошенное количество дней.
• Форма содержит хотя бы одно поле даты, если вы хотите, чтобы годовой поиск entries опирался на дату отпуска, а не только на дату отправки.
• Валидация не позволяет отправить пустое или очевидно неверное количество дней.

Секция отпускной информации в профиле пользователя

Расширение добавляет отпускные поля в профиль пользователя WordPress. Документация описывает компоненты формулы так: Annual Paid Time Off + Comp Days + HR Adjustment + Carry Over Days - Days Approved. На практике это означает, что HR должен понимать назначение каждого значения.

Баланс не стоит воспринимать как бухгалтерский регистр, если компания требует юридически точного кадрового учёта. Это удобный operational layer внутри WordPress. Для кадрового отдела полезно договориться, какой источник считается главным: WordPress-портал, HR-система или ручной кадровый журнал.

Вывод остатка на странице и в уведомлениях

Документация описывает shortcode [gravityflow page="vacation"], который выводит текущий balance для текущего пользователя. У shortcode есть атрибут data, с помощью которого можно показать отдельные значения: pto, comp_days, hr_adjustment, carry или approved. Например, [gravityflow page="vacation" data="comp_days"] показывает компенсационные дни.

Для уведомлений используется merge tag {workflow_vacation} с модификаторами pto, comp_days, hr_adjustment, carry, approved и balance. Важный нюанс: документация предупреждает, что merge tag в workflow notification не включает текущую запрошенную заявку, если workflow ещё не завершён, потому что расчёт требует завершения процесса. Если нужно показать approved days текущей entry, используйте Gravity Forms notification там, где это соответствует логике процесса.

Безопасное оформление блока баланса без правки плагина

Если нужно аккуратно оформить вывод остатка на закрытой странице сотрудника, не меняйте файлы Gravity Flow или расширения. Создайте обычный блок HTML вокруг shortcode и добавьте CSS в дочернюю тему или в штатное место для пользовательских стилей темы. Такой подход не зависит от внутренних классов плагина и легко откатывается.

<div class="gf-vacation-balance">
  <h3>Остаток отпускных дней</h3>
  [gravityflow page="vacation"]
</div>

.gf-vacation-balance {
  max-width: 520px;
  padding: 18px 20px;
  border: 1px solid #d7e2ef;
  border-radius: 8px;
  background: #f7fbff;
}

.gf-vacation-balance h3 {
  margin-top: 0;
  font-size: 1.1rem;
}

Проверка простая: откройте страницу под тестовым сотрудником, убедитесь, что shortcode выводит значение, затем временно удалите CSS или блок-обёртку и проверьте, что сама логика баланса не зависит от оформления. Откат - удалить wrapper и CSS, данные заявок при этом не затрагиваются.

Маршрут заявки: сотрудник, руководитель и HR

Отпускной процесс обычно строится вокруг трёх шагов: manager approval, modification by submitter и HR processing. Документация Gravity Flow использует похожий пример для первого workflow: сотрудник отправляет request, руководитель approve или reject, при approve HR добавляет заметки, например о remaining days. Расширение Vacation Requests делает этот сценарий предметнее, потому что в форме появляется отпускное поле, а в профиле пользователя - баланс.

Шаг руководителя

В форме откройте Settings -> Workflow, добавьте новый шаг и выберите step type Approval. В настройках укажите assignee. Это может быть конкретный пользователь, роль, email field или более сложная conditional routing-логика, если руководитель зависит от отдела. Для первого запуска лучше выбрать конкретного тестового руководителя, а маршрутизацию по отделам добавить после успешной проверки базового процесса.

В step settings задайте display fields: руководитель должен видеть имя сотрудника, даты, Vacation Days, комментарий сотрудника и, если уместно, остаток. Служебные поля HR лучше не показывать на этом шаге. Если нужно дать руководителю возможность исправить число дней, сделайте это осознанно и проверьте, кто отвечает за финальное значение.

Approval, Reject и Revert

Стандартный approval step умеет approval, rejection и revert, если в workflow есть user input step. Для отпусков revert полезен, когда руководитель не хочет просто отклонить заявку, а просит сотрудника изменить даты или комментарий. Тогда entry отправляется на шаг доработки без потери истории.

Настройте тексты писем так, чтобы пользователь понимал статус. В письме руководителю должны быть ссылка на задачу и главные поля заявки. В письме сотруднику после rejection или revert должно быть ясно, что именно требуется исправить. Не перегружайте письмо всеми служебными полями: подробный контекст лучше оставить на detail page.

Шаг доработки сотрудником

Шаг User Input позволяет получить дополнительные данные после отправки формы. Для отпускной заявки он нужен, если руководитель возвращает запрос из-за неверных дат, пересечения с важным периодом или неправильного количества дней. В настройках user input step выберите editable fields: обычно это даты, количество дней и комментарий сотрудника. Поля HR и служебные поля баланса должны оставаться недоступными.

Включайте highlight editable fields, если пользователи часто путаются, что можно менять. Документация Gravity Flow описывает два варианта подсветки editable fields: green triangle и green background. Для внутренних порталов это удобнее, чем длинная инструкция в письме.

Шаг HR Processing

После approval руководителя заявка уходит в HR processing. Здесь HR проверяет служебную информацию, при необходимости добавляет внутреннюю заметку, сверяет количество дней и завершает workflow. Если поле Vacation Days заполнено корректно и финальный статус approved, расширение учитывает эти дни в балансе пользователя.

Хорошая практика - не давать HR processing слишком много автоматических действий на первом этапе. Сначала пусть HR вручную сверяет заявку и пишет note. Когда процесс станет стабильным, можно думать об интеграциях, календарях или отчётах. Так меньше риск списать неверное количество дней из-за ошибки в поле или условной маршрутизации.

Практический пример: заявка на отпуск с проверкой остатка дней

Ниже - пример настройки для небольшой компании, где сотрудники входят в закрытый портал WordPress, руководитель согласует отпуск, а HR контролирует остаток. Это не единственный возможный сценарий, но он хорошо показывает, как пользоваться Gravity Flow Vacation Requests без лишней сложности.

Цель

Нужно получить процесс, в котором сотрудник отправляет даты отпуска и количество дней, руководитель принимает решение, при необходимости возвращает заявку на исправление, HR завершает обработку, а сотрудник видит статус и может посмотреть свой остаток отпускных дней на отдельной странице.

Подготовка

• На тестовом сайте активны Gravity Forms, Gravity Flow и Vacation Requests.
• Созданы пользователи employee-test, manager-test и hr-test.
• Для HR-пользователя выданы права на просмотр workflow и редактирование отпускной информации в профиле.
• Созданы страницы Submit, Inbox, Status и отдельная страница с shortcode баланса.
• Страницы workflow исключены из кеша и проверены в режиме приватного окна.

Шаги настройки

1. Создайте форму Vacation Request в Gravity Forms.
2. Добавьте поля имени, отдела, даты начала, даты окончания, комментария сотрудника и Vacation Days.
3. Добавьте административное поле HR Comments и настройте visibility как administrative, если оно должно быть скрыто от submitter.
4. В профиле employee-test заполните отпускные значения, например базовые дни и перенос.
5. В Settings -> Workflow добавьте approval step Manager Approval и назначьте manager-test.
6. Добавьте user input step Employee Revision и разрешите редактировать только даты, Vacation Days и комментарий.
7. В approval step включите revert к Employee Revision, если руководитель должен возвращать заявку на исправление.
8. Добавьте user input или approval-подобный HR step HR Processing, назначьте hr-test и покажите HR-поля.
9. Настройте emails для assignee, approval и rejection, используя понятные темы и merge tags.
10. Отправьте тестовую заявку от employee-test через страницу Submit.

Проверка результата

После отправки заявки руководитель должен увидеть entry во Inbox. Если он нажимает reject, workflow должен остановиться или уйти по выбранному вами reject path. Если он выбирает revert, сотрудник должен получить задачу на исправление и увидеть только editable fields. Если руководитель нажимает approve, заявка должна перейти к HR.

После финального approved состояния откройте страницу с [gravityflow page="vacation"] под сотрудником. Баланс должен учитывать approved days. Если значение не изменилось, не делайте вывод сразу. Проверьте, завершён ли workflow, заполнено ли поле Vacation Days, является ли отправитель текущим пользователем и есть ли date field, по которому корректно определяется период расчёта.

Нюанс, который часто упускают

Merge tag {workflow_vacation:balance} в workflow notification может не включать текущую заявку, если процесс ещё не завершён. Поэтому не стройте письмо руководителю так, будто оно показывает будущий баланс после одобрения. Лучше формулировать осторожно: "текущий доступный баланс" и отдельно показывать requested days из entry.

Как работает расчёт дней и почему его нужно проверять отдельно

Расчёт отпускного остатка кажется простым, но именно здесь чаще всего возникают управленческие ожидания, которые не совпадают с возможностями расширения. Документация описывает формулу баланса и уточняет, что Days Approved считается поиском entries по всем формам с полем Vacation Days. Поиск ограничен текущим годом, а датой считается первое date field на форме; если date fields нет, используется submission date.

Из этого следуют практические правила. Первое: в форме должны быть даты, если вы хотите считать отпуск по периоду самого отпуска, а не по дате отправки. Второе: если на сайте несколько отпускных форм, поле Vacation Days в каждой из них участвует в общей логике approved days. Третье: перенос через границу года нельзя оставлять одной заявкой, если вы хотите следовать documented limitation.

Проверка на тестовых entries

Создайте три тестовые заявки под одним пользователем: одну rejected, одну approved на небольшое количество дней и одну pending. После завершения approved workflow проверьте баланс. Он должен измениться только после approved-заявки, а pending и rejected не должны списывать дни как завершённый approved отпуск.

Затем создайте заявку с датой в другом периоде, если это важно для вашей политики. Так вы увидите, как работает годовое ограничение поиска. Не переносите этот тест на реальных сотрудников без согласования с HR, потому что отпускные значения в профиле могут стать предметом спора.

Граница двух лет

Официальная документация прямо указывает, что vacation requests spanning two years нужно делать двумя отдельными requests. В русской инструкции для сотрудников это лучше описать без технических деталей: "Если отпуск начинается в конце одного года и заканчивается в начале следующего, оформите две заявки - отдельно на дни первого года и отдельно на дни следующего".

Заявка за другого сотрудника

Второе documented limitation - form submitter получает time off, и текущая версия не позволяет отправить vacation request on behalf of another user. Поэтому HR-сценарий "оформить отпуск за сотрудника" лучше решать организационно: попросить сотрудника отправить заявку самостоятельно, либо строить отдельный процесс вне Vacation Requests, если такая операция обязательна.

Проверка перед запуском для всей компании: попросите HR подтвердить, что формула баланса, годовое ограничение, правило двух заявок на переход года и невозможность заявки за другого пользователя соответствуют внутренней политике.

Страницы Inbox, Status, Submit и вывод баланса на сайте

Даже если вся админка работает, пользовательский сценарий может сломаться на фронтенд-страницах. Gravity Flow даёт блоки и shortcode для Inbox, Status, Reports и Submit. Для отпусков обычно достаточно Submit для отправки, Inbox для задач согласования, Status для отслеживания и отдельного блока баланса. Но эти элементы нужно размещать аккуратно.

Не смешивайте несколько workflow-блоков на одной странице

Документация по blocks указывает, что блоки рассчитаны на отдельные страницы и не следует объединять несколько Gravity Flow blocks на одном post/page. На практике это предотвращает конфликт фильтров, путаницу с detail view и проблемы с отображением. Сделайте отдельные страницы, дайте им понятные URL и добавьте их в меню закрытого портала.

Когда использовать block, а когда shortcode

Если сайт использует редактор блоков и текущую тему, удобнее ставить Gravity Flow block. Если страница собирается старым редактором, page builder или шаблонной областью, shortcode может быть проще. В любом случае копируйте shortcode с прямыми ASCII-кавычками: документация по email-field assignee issues отдельно упоминает, что curly quotes внутри shortcode могут привести к проблемам.

Для отпускного баланса используйте documented shortcode [gravityflow page="vacation"]. Если нужно показать не весь balance, а отдельное значение, добавляйте data. Не вставляйте несколько вариантов на одну страницу без необходимости: сотруднику обычно нужен понятный итог, а не набор технических составляющих формулы.

Кеш и оптимизация

Страницы Workflow нельзя кешировать так же агрессивно, как обычную статью. Support-документация Gravity Flow связывает ошибку "The link to this form is no longer valid" с кешированием submission page, а пустой Inbox для email assignees - с aggressive caching. Исключите Submit, Inbox, Status и страницы entry detail из кеша, проверьте серверный кеш хостинга, CDN и оптимизаторы скриптов.

Если сайт использует Cloudflare, security plugin или защиту от длинных URL, проверяйте email approval links и assignee links отдельно. Некоторые workflow-ссылки содержат параметры, и защитные правила могут воспринимать их как подозрительные. Не отключайте безопасность целиком на рабочем сайте; сначала протестируйте конфликт на staging или через Health Check & Troubleshooting.

Проверка уведомлений, прав и приватности

Отпускные заявки содержат персональные данные, поэтому настройка уведомлений должна быть строже, чем у обычной контактной формы. Руководителю нужен контекст для решения, сотруднику нужен понятный статус, HR нужны служебные поля. Но не всем нужны все поля одновременно.

Что включать в письма

В assignee email руководителю добавьте ссылку на задачу, имя сотрудника, даты, requested days и комментарий. Если показываете balance, подпишите его как текущий остаток, а не как guaranteed balance after approval. В письме сотруднику после отправки укажите, что заявка ожидает согласования, и дайте ссылку на Status page, если пользователь должен отслеживать ход процесса.

В approval email после финального завершения можно добавить понятный результат: заявка approved, количество дней учтено, проверьте страницу баланса. Если уведомление отправляется до полного завершения workflow, не используйте формулировки, которые обещают уже списанный остаток.

Права на просмотр статуса

По умолчанию Gravity Flow ориентирован на intranet/extranet-сценарии, где пользователи входят в систему, а inbox и status недоступны незалогиненным посетителям. Документация также описывает возможность назначать steps email field assignees и открывать доступ через shortcode attributes, но для отпусков такой режим требует отдельной оценки. Чем больше персональных данных в форме, тем осторожнее нужно относиться к anonymous access.

Административные поля и внутренние заметки

Служебные поля HR должны быть administrative или ограничены display settings конкретного step. Не добавляйте их в публичный Status view без проверки. Если HR пишет в note причину корректировки, помните, что workflow timeline может быть виден тем ролям, которым разрешён detail view. Лучше заранее решить, какие комментарии являются внутренними, а какие можно показывать сотруднику.

Практический тест приватности: пройдите один workflow под каждым тестовым пользователем и сделайте скриншот того, что видит сотрудник, руководитель и HR. Если сотрудник видит внутренние HR notes или административное поле, исправьте display fields и visibility до запуска.

Диагностика проблем с Gravity Flow Vacation Requests

Ошибки отпускного workflow обычно появляются не из-за самого поля Vacation Days, а на стыке прав, кеша, shortcode, email links и неверного статуса entry. Ниже - практическая диагностика, которую стоит пройти до обращения в поддержку.

Поле Vacation Days не видно в редакторе формы

Симптом: администратор открыл Gravity Forms form editor, но не видит нужное поле расширения. Возможные причины - расширение не активировано, не активен Gravity Flow, используется не та форма или пользователь не имеет нужных прав на редактирование формы.

Что проверить: список активных плагинов, наличие Gravity Forms и Gravity Flow, правильную форму, а также отсутствие конфликтного режима в админке. Если поле появилось после отключения другого админского оптимизатора, возвращайте плагины по одному и фиксируйте конфликт.

Баланс не меняется после одобрения заявки

Симптом: заявка approved, но [gravityflow page="vacation"] показывает прежний остаток. Проверьте, завершён ли весь workflow, заполнено ли поле Vacation Days, относится ли entry к текущему пользователю, есть ли date field и не тестируете ли вы merge tag в workflow notification до завершения процесса.

Как исправить: завершите HR step, убедитесь, что финальный статус approved, откройте страницу под тем же пользователем, который отправил форму. Если заявка пересекает два года, разделите её на две. Если HR отправлял форму за сотрудника, учитывайте documented limitation: отпуск списывается с submitter.

Workflow menu или Inbox недоступны нужной роли

Симптом: пользователь не видит меню, Inbox или Status. Официальная support-страница связывает отсутствие Workflow menu с permissions. Проверьте capabilities роли: доступ к inbox, status, submit, activity, настройкам workflow и редактированию профилей должен соответствовать задачам пользователя.

Когда откатывать настройку: если вы выдали слишком широкие права и пользователь увидел чужие заявки, верните роль к минимальному набору capabilities и создайте отдельную тестовую роль для руководителей.

Email-ссылка открывает ошибку "The link to this form is no longer valid"

Симптом: assignee переходит из письма и видит предупреждение, что ссылка больше не действительна. Документация Gravity Flow указывает частую причину - submission page кешируется. Исключите страницу из кеш-плагина, серверного кеша и CDN. Если хостинг управляет кешем сам, отправьте запрос в поддержку хостинга.

Что проверить дополнительно: security plugin, длинные URL, Cloudflare settings и корректность quotes в shortcode. Не заменяйте shortcode вручную на типографские кавычки.

Фронтенд shortcode выглядит не так, как в документации

Симптом: Inbox или Status выводится с неправильными шрифтами, кнопками или отступами. Support-документация объясняет, что внешний вид shortcode зависит от активной темы, а visual editor может обернуть shortcode в <pre>. Проверьте HTML в текстовом режиме и удалите лишнюю обёртку.

Как исправить безопасно: используйте block, если тема его поддерживает, или добавьте CSS вокруг собственной обёртки, как показано выше. Не правьте файлы плагина и не стирайте стили Gravity Flow глобально.

Email assignee видит пустой Inbox или ошибку доступа

Симптом: entry назначена email assignee, но фронтенд Inbox пустой или ссылка сообщает, что доступа нет. Документация перечисляет несколько причин: aggressive caching, Cloudflare Email Address Obfuscation, security plugin, curly quotes в shortcode и несколько Gravity Forms или Gravity Flow shortcodes на одной странице.

Порядок проверки: временно исключите страницу из кеша, проверьте shortcode, уберите лишние workflow-shortcodes со страницы, отключите email obfuscation для теста и проверьте Health Check & Troubleshooting. Если проблема исчезла, возвращайте настройки по одной.

Когда Gravity Flow Vacation Requests будет удачным выбором

Gravity Flow Vacation Requests подходит, если ваш сайт уже использует Gravity Forms и Gravity Flow, а отпускной процесс должен жить внутри WordPress: отправка заявки, approval руководителя, возможная доработка, HR processing, статус и расчёт остатка дней. Сильная сторона расширения - не красивая форма сама по себе, а связка workflow steps с отпускным балансом пользователя.

Перед запуском на рабочем портале проверьте четыре вещи: сотрудники отправляют заявки от своих аккаунтов, страницы workflow не кешируются, HR понимает формулу баланса, а ограничения по двум годам и заявке за другого пользователя приняты внутренней политикой. После этого можно переходить от тестового сценария к рабочему и постепенно добавлять календарь, отчёты или интеграции, если они действительно нужны.

Если после проверки расширение подходит вашему процессу, можно скачать последнюю версию Gravity Flow Vacation Requests и развернуть его сначала на тестовом сайте. Не запускайте заявки для всех сотрудников в день установки: один полный тестовый workflow с сотрудником, руководителем и HR обычно экономит больше времени, чем последующая диагностика перепутанных прав и неверного баланса.