Заметки
После обновления CRM-страница даёт 500
После обновления CRM-страница даёт 500: Логи, консоль, права файлов, миграции.
После обновления CRM-страница даёт 500. Основной фокус: Логи, консоль, права файлов, миграции.
Задача
Разобрать коробочную диагностику: обновление, 500, cron, доступ, сеть или восстановление.
Задача — после обновления CRM-страница даёт 500. Логи, консоль, права файлов, миграции.
Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.
Как это устроено
В коробке результат зависит не только от кода Битрикса, но и от окружения: PHP, права файлов, nginx/apache, php-fpm, cron, база, сеть и локальные доработки.
В Bitrix24 права почти всегда считаются не одной настройкой, а комбинацией роли, группы, структуры, владельца, привязки к сущности и контекста текущего пользователя.
Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.
Рабочий подход
Собирайте диагностику слоями: логи PHP и веб-сервера, консоль браузера, агенты, права файлов, состояние модулей, кеш и последние изменения. На бою сначала фиксируйте текущее состояние, потом меняйте.
Сразу соберите логи PHP, веб-сервера и консоль браузера. Если ошибка появилась после обновления, отдельно проверьте кеш, права файлов и локальные доработки.
На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.
Частые ошибки
Не правьте ядро и не отключайте права как быстрый фикс. После обновления такой костыль обычно ломается повторно и усложняет диагностику.
- Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
- Пытаться решить доступ скрытием элемента интерфейса, хотя данные остаются доступны через другой путь.
- Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.