← Назад к заметкам

Заметки

Почему созданное событие календаря не кликабельное

Почему событие календаря, созданное из 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,
]);