Документация для разработчиков
Темная тема

Relation

\Bitrix\Crm\Relation - основной класс, в котором сосредоточена большая часть логики API связей. Объект этого класса представляет собой конкретный тип связи между сущностями CRM, например Сделка — Предложение. Именно через этот объект происходит привязка и отвязка элементов, проверка на связь и получение связанных элементов.

Методы для работы с элементами

Когда в RelationManager происходит работа с элементами (проверка на существование связи, связывание/отвязывание элементов), то он по факту обращается к методам объекта Relation. А именно:

  • areItemsBound(
       ItemIdentifier $parent,
       ItemIdentifier $child
    ): bool
  • bindItems(
       ItemIdentifier $parent,
       ItemIdentifier $child
    ): \Bitrix\Main\Result
  • getParentElements(
       ItemIdentifier $child
    ): ItemIdentifier[]
  • и другие...

Сейчас в CRM существует множество различных типов связи, каждый из которых по-своему реализуется со стороны БД. Поэтому Relation при работе с элементами использует паттерн проектирования Стратегия Стратегия - поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости.
Подробнее...
.

\Bitrix\Crm\Relation\StorageStrategy - базовый класс стратегии по работе с БД (стратегии хранения данных). Он предоставляет для Relation публичный интерфейс, посредством которого методы работы с элементами взаимодействуют с БД. То, какая именно стратегия будет применяться для данного типа связи, конфигурируется посредством метода:

\Bitrix\Crm\Relation::setStorageStrategy(
   StorageStrategy $storageStrategy
): Relation

В него в качестве параметра передается инстаницированный объект стратегии.

Для работы методов, которые взаимодействуют с элементами, необходим объект стратегии. Поэтому при вызове этих методов до того, как стратегия была установлена через этот метод, будет выброшено исключение.

Стандартные (предопределенные) и кастомные типы связи

Типы связи могут быть двух видов:

  • стандартные (predefined) - те, что заданы на уровне бизнес-логики и продуктовых решений. Стандартные типы связи не могут быть удалены, изменены. Не может быть создан кастомный тип связи, дублирующий стандартный. Пример: продукт-менеджер решил, что к Сделке можно привязать Предложение.
  • кастомные (custom) - те, которые клиентский код может создать и настроить самостоятельно.Кастомные типы связи находятся полностью во власти клиентского кода. Вы можете их создавать, редактировать, удалять на свое усмотрение. Пример: администратор портала решил, что Смарт-процесс "Реестр договоров" можно привязать к Сделке.

Узнать, к какому конкретно виду принадлежит данный объект Relation можно с помощью метода Relation::isPredefined.

Создание нового объекта

Чтобы инстанцировать новый объект Relation используется фабричный метод Relation::create. В него передаются следующие параметры:

  • int $parentEntityTypeId - идентификатор родительского типа сущности,
  • int $childEntityTypeId - идентификатор типа сущности потомка,
  • bool $isChildrenListEnabled = true - должен ли быть показан грид потомков в детальной карточке родительского элемента (например, как вкладка "Предложения" в карточке сделки). По умолчанию true.

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.
© «Битрикс», 2001-2023, «1С-Битрикс», 2023
Наверх