Пользователь, элемент инфоблока, раздел инфоблока — все это расширяемые сущности в «1С-Битрикс: Управление сайтом». Помимо тех полей, которые уже предоставляет система, администратор сайта или разработчик может создавать новые свойства.
Например, у пользователя есть поле Телефон, но нет поля «Запасной телефон», а у элемента инфоблока есть поле «Название», но нет поля «Название на английском».
В ходе предпроектного анализа и составления технического задания в таких полях может возникнуть необходимость. Появление нескольких десятков новых свойств — не редкость в реальных проектах.
У администратора сайта и разработчика всегда есть выбор: использовать для данных существующее поле или создать новое. Первый вариант подходит, если не происходит искажения изначального смысла поля. Например, технически ничто не мешает вносить «Запасной телефон» в поле «Отчество» и отразить это изменение в документации к сайту. Но в программном коде неизбежно возникнет путаница. Поэтому так лучше не делать.
Для «Запасного телефона» пользователя или «Названия на английском» элемента инфоблока лучше создавать новые свойства.
Пользовательские поля и свойства
Так как разные готовые сущности «1С-Битрикс: Управление сайтом» были разработаны для разных задач, то и «под капотом» они устроены по-разному. Поэтому и механика добавления новых свойств в сущности разная.
В этой теме мы затронем два самых обширных механизма, на самом деле их гораздо больше.
Необходимо отличать Пользовательские поля (часто их называют UF-полями) в модулях системы и свойства используемые в рамках инфоблоков, хотя в формах системы (форма создания/редактирования пользователя, форма создания/редактирования раздела инфоблока и другие) используется термин пользовательские свойства.
Пользовательские поля (UF)
Это универсальный механизм, который позволяет хранить значения свойств для произвольных сущностей в БД.
Интерфейс администратора для этого механизма есть у множества сущностей: у пользователей, у разделов инфоблоков, у складов интернет-магазина и у основных сущностей модуля CRM.
При создании пользовательского поля администратор должен указать объект (сущность), к которой будет привязано свойство. В нашем примере — USER, пользователь из главного модуля. Не какой-то конкретный пользователь, а само понятие «Пользователь».
Кроме объекта, указываются основные поля: Тип данных, Код, внешний код XML_ID, сортировка, множественность, обязательность, учет в поиске и фильтре, подпись поля на страницах административного раздела.
Эта форма создает поле, которое будет добавлено в форму редактирования пользователя, в список пользователей и фильтр.
Это универсальный механизм, который можно использовать для любой сущности, даже для своей собственной (о разработке собственных сущностей будут отдельные уроки). Но важно понимать, что этот механизм добавляет только API для управления данными — интерфейс для управления данными разработчик собственной сущности должен сделать сам.
Свойства инфоблока
Создание пользовательского свойства для элементов инфоблока (в документации обычно используется сокращенное название «Свойства инфоблока») происходит в другом интерфейсе, но параметры свойства нужно определить те же.
Объект указывать не нужно, так как свойства создаются непосредственно из формы редактирования инфоблока. Остальные важные поля: название, тип, символьный код, порядок сортировки, множественность, обязательность, учет в поиске и фильтре.
Базовые типы данных
При создании пользовательских полей (UF) и пользовательских свойств инфоблоков, администратор должен выбрать тип поля. В оба механизма заранее встроены как базовые типы данных (строка, число, файл и т.п.), так и наиболее полезные для разработки (привязка к Яндекс.Карте, привязка к пользователю, к элементу инфоблока и т.д.).
Полезно
- Тип данных пользовательских полей главного модуля (UF), таблица "Форма редактирования".
- Тип данных пользовательских полей инфоблоков, таблица "Свойства".
Список типов не ограничен только этими вариантами. Любой модуль из более старших редакций, из Маркетплейса и даже ваш собственный, может добавить свои собственные типы.
Создание собственных типов свойств — частая задача при разработке сайта. Чаще всего речь идет про привязку к каким-либо данным в самой платформе. В практической части этого урока, например, мы создадим тип данных «Привязка к группе пользователя».
При этом важно отличать внешний вид свойства в форме редактирования в списке и то, как данные хранятся в БД. Обычно в БД для таких свойств хранится уникальный идентификатор соответствующей записи, как правило — int, и только при выводе добавляется связанная информация.
Например, свойство типа «Привязка к элементам в виде списка» в форме редактирования выглядит как select с названиями элементов инфоблока.
В списке элементов инфоблока — как название и кликабельный идентификатор-ссылка на связанный элемент. При этом в базе данных хранится не строка с названием, а именно целочисленный ID связанного элемента.
Возвращаясь к практической теме нашего урока. Если бюджет или срок проекта ограничен и нет возможности создать новый тип данных «Привязка к группе пользователя» можно создать числовое свойство для хранения идентификатора группы. И впоследствии уже, когда бюджет и срок позволят, добавить удобный интерфейс администратору с выпадающим списком.
Последнее напутствие — прежде чем разрабатывать собственный тип данных, попробуйте найти готовое решение в Маркетплейсе приложений. Есть большая вероятность, что вы не первые столкнулись с этой необходимостью.
Практика
Покажем как привязать пользователя к “запасной” группе или к группе, в которую он хочет чтобы его добавили.
Дополнительные свойства
5 мин
Полезные ссылки и материалы