Устранение неполадок¶

Большинство проблем сводится к тому, что фоновые задания не выполняются, или к настройке, из-за которой не приходит почта. Начните с отчёта о состоянии, затем найдите свой симптом ниже.

Отчёт о состоянии¶

Откройте Operations → System в рабочей области (#/setup/system), выполните на сервере bin/plugin helpdesk-pro status, вызовите GET /helpdesk-pro/status (нужно helpdesk-pro.settings) или используйте инструмент MCP get_status. Все четыре способа сообщают одно и то же:

Запланированные задания — это нормально: периодические обходы всегда запланированы на будущее. Внимания требуют только ожидающие задания, которые так и лежат, или неудачные, и только они превращают строку Jobs на экране System в предупреждение.

Задания ждут, и ничего не отправляется¶

stale: true означает, что задания ждут больше десяти минут и фоновый процесс не запускался столько же. Либо cron не запускает планировщик Grav, либо запускает, но bin/plugin не может найти PHP.

1. Проверьте, что в crontab есть строка планировщика и строка PATH (см. Задания и cron).
2. Запустите bin/grav scheduler -d, чтобы увидеть ошибки каждого задания. env: php: No such file or directory означает, что строка PATH отсутствует или неверна.
3. Выполните bin/plugin helpdesk-pro work вручную, чтобы один раз обработать очередь.

Задание постоянно завершается с ошибкой¶

bin/plugin helpdesk-pro jobs --state=failed   # неудачные задания с последней ошибкой
bin/plugin helpdesk-pro jobs --run=<id>       # запустить одно снова после исправления причины

База данных доступна для скачивания на nginx или Caddy¶

Запрещающий всё .htaccess защищает базу данных только на Apache. На других серверах запретите доступ к user/data/ в конфигурации сервера. Для nginx:

location ^~ /user/data/ { deny all; }

Письма в поддержку не приходят¶

Начните с Operations → Email (или GET /helpdesk-pro/inbound/status). Список проблем называет то, что мешает почте приходить: плагин Email старше 5.3.0, входящая почта выключена, секрет короче 32 символов, нет адреса поддержки или приёмника, которого нет на сайте. Затем проверьте, что видел ваш провайдер при отправке:

Письмо, которое всё-таки пришло, находится в Operations → Inbound log с причиной того, что с ним произошло; Retry или Process again запускает его снова после исправления. Ответ сотрудника, застрявший в состоянии held, не прошёл проверку отправителя и ждёт Release. Для IMAP раздел Mailbox в Operations → Email показывает последнюю ошибку. См. Входящую почту.

Ответы по почте открывают новые заявки¶

Вероятно, ваша почтовая система не доставляет support+anything@ туда же, куда support@, поэтому токен ответа теряется. Включите плюс-адресацию у провайдера (см. Какой адрес) или установите inbound.plus_addressing в false и полагайтесь на заголовки группировки.

Ссылки в письмах клиентам ведут на неверный адрес¶

Ссылки в письмах строятся от адреса, по которому сайт последний раз посещали. Установите email.site_url в адрес, которым пользуются клиенты, например https://example.com. Тестовое письмо сообщает, что ссылки относительные, если адрес ещё неизвестен.

Письмо-уведомление приходит поздно¶

Письмо-уведомление никогда не отправляется в том же запросе, который его создал, поэтому ему нужен фоновый процесс. Без cron догоняющая обработка отправит его после следующего посещения сайта. Настройте cron (см. Задания и cron).

Обновления в реальном времени не приходят¶

Блок realtime в отчёте о состоянии сообщает, включены ли обновления, какой транспорт их доставляет и почему нет, когда они выключены: плагин Sync отсутствует или отключён, realtime.enabled выключен или установленный Sync Mercure старше 1.2.2 (тогда браузеры переходят на опрос). live_listeners считает людей с открытой живой вкладкой. Всё остальное продолжает работать без обновлений в реальном времени. См. Обновления в реальном времени.

Правило не сработало¶

1. Откройте Automation → Rules. У правила с ошибкой последняя ошибка показана в его строке (исполнитель, который больше не работает в проекте, удалённый сохранённый ответ); сохранение правила очищает её.
2. Откройте правило и используйте Test against ticket с номером заявки. Он покажет, какие условия заявка выполняет сейчас.

Изменение, сделанное правилом, никогда не запускает правила, поэтому правило, ждущее «изменения статуса», не сработает, когда статус изменило другое правило. Правило срабатывает один раз на событие, а правило по времени — один раз на пребывание в состоянии. Правила по времени и автоматическое закрытие выполняются заданием rules.sweep каждые десять минут, поэтому им нужен фоновый процесс или догоняющая обработка.

Удаление не произошло¶

Удаление выполняется как задание people.erase, поэтому ему нужен фоновый процесс или встроенная обработка. «Erasure queued», которое никогда не меняется, означает, что задание не запускается: проверьте bin/plugin helpdesk-pro jobs --type=people.erase. Отчёт held означает, что юридическое удержание было наложено после запроса удаления; снимите его и удалите снова. bin/plugin helpdesk-pro erase <id> выполняет удаление сразу.

У заявителя указано «account not verified»¶

Кто-то зарегистрировался на сайте с этим адресом, но так и не подтвердил его, поэтому его учётная запись и обращения с этого адреса хранятся отдельно (см. Люди и конфиденциальность). Заявки, которые вы открываете для этого адреса, всё равно доходят до нужного человека. Клиент объединит их, воспользовавшись любой ссылкой для входа или пунктом «Verify your email» в портале. Вы также можете объединить две записи на странице человека, когда знаете, что это один и тот же человек.

Поиск чего-то не находит¶

Выполните bin/plugin helpdesk-pro reindex --status, чтобы увидеть состояние индекса, затем bin/plugin helpdesk-pro reindex, чтобы перестроить его. Статьи, изменённые вне Grav (git sync, FTP, развёртывание), подхватываются ежечасным заданием kb.sync. Проверьте, что статья опубликована, имеет маршрут и доступна человеку, который ищет (см. Базу знаний).

Связанные разделы¶

• Задания и cron
• CLI
• Входящая почта
• Конфигурация