Заметки
Почему созданное событие календаря не кликабельное
Почему событие календаря, созданное из PHP, может не открываться нормально: поля календаря, владелец, тип и встреча.
В заметке разбираем тему: Почему созданное событие календаря не кликабельное. Главное — не переносить решение вслепую с другого портала, а проверить контекст коробки, права, версию модулей и фактические данные.
Задача
Почему событие календаря, созданное из PHP, может не открываться нормально: поля календаря, владелец, тип и встреча.
Сценарий обычно появляется в коробочной доработке, когда нужно быстро решить практическую задачу, но при этом не сломать обновления, права и штатную логику портала.
Ключевые вещи в этой теме: поля календаря, тип, владелец. Именно их стоит проверить первыми, прежде чем менять код.
Как это устроено
В коробке важно отделять штатный API, контекст запуска и прямую правку файлов.
Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.
Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.
Если поведение отличается под администратором и обычным сотрудником, почти всегда нужно отдельно проверить права, категорию сущности, владельца записи и пользователя, от имени которого выполняется код.
Рабочий подход
Сначала зафиксируйте контекст, потом проверяйте API и только после этого меняйте данные.
- Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
- Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
- Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
- Для боевого портала добавьте логирование результата и ошибок.
Частые ошибки
Большинство проблем появляется из-за неверного контекста или обхода штатной логики.
- Код проверяют только под администратором, а потом он не работает у сотрудников.
- Доработку кладут в
/bitrixили в перегруженныйinit.phpвместо/localили модуля. - Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
- Данные меняют напрямую, минуя операции, события, права, индексы и кеш.
Минимальный пример
Пример показывает базовую форму. ID, пути, названия модулей и поля нужно заменить под свой портал.
<?php
$event = CCalendarEvent::GetById($event_id);
print_r([
'ID' => $event['ID'] ?? null,
'CAL_TYPE' => $event['CAL_TYPE'] ?? null,
'OWNER_ID' => $event['OWNER_ID'] ?? null,
'SECTION_ID' => $event['SECTION_ID'] ?? null,
'IS_MEETING' => $event['IS_MEETING'] ?? null,
]);