Перейти к содержимому
BXWiki

Список как справочник - поля, права, вывод и наполнение

Заводим справочник, который ведёт сотрудник без разработчика: свои поля, свои права и вывод на сайте обычной выборкой.

Решение

Выбираем между тремя хранилищами:

универсальный список - сотрудник сам заводит поля и правит записи
highload-блок        - сотни тысяч записей, поля заводит разработчик
инфоблок             - разделы, права на элементы, привязка файлов
// для справочника отделов, статусов и причин отказа обычно берут первый

Список выигрывает там, где данные ведёт сотрудник. Новое поле в нём добавляют через интерфейс, и очередная просьба «добавьте колонку» перестаёт быть задачей для разработчика.

Смотрим, чем список является на самом деле:

\Bitrix\Main\Loader::includeModule('lists');
$res = CIBlockElement::GetList([], ['IBLOCK_ID' => $listIblockId, 'ACTIVE' => 'Y'],
    false, false, ['ID', 'NAME', 'PROPERTY_STATUS']);
// список - это инфоблок особого типа, и читается он обычной выборкой

Список читается тем же кодом, что и инфоблок. Это и есть его главное удобство для разработчика: никакого нового API учить не нужно, а поля списка приходят обычными свойствами.

Раздаём права на ведение:

- права на сам список задаются в его настройках, отдельно от прав сайта
- обычно: отдел ведёт свой список, остальные видят его только на чтение
- правка полей списка - отдельное право, и его дают не всем

Права на список задаются отдельно от прав сайта. Это позволяет отдать справочник отделу целиком, не пуская его в остальные разделы административной части.

Наполняем список из файла:

foreach ($rows as $row) {
    $el = new CIBlockElement();
    $el->Add(['IBLOCK_ID' => $listIblockId, 'NAME' => $row['name'],
        'PROPERTY_VALUES' => ['CODE' => $row['code']]]);
}
// первичное наполнение делают скриптом, дальше список ведёт сотрудник

Первое наполнение делают скриптом, дальше список живёт руками. Заводить сотню записей через интерфейс никто не станет, а десяток правок в месяц сотрудник сделает быстрее, чем напишет вам задачу.

Списку стоит сразу задать код записи, а не только название. Название меняется, а код остаётся, и весь код проекта опирается именно на него.

Список не годится там, где записей десятки тысяч. Интерфейс правки на таком объёме становится неудобным, а выборки - медленными: это случай для highload-блока.

Ответственного за справочник называют сразу. Список без хозяина за год превращается в набор из трёх похожих записей с разными опечатками.

Выбор хранилища стоит делать один раз и осознанно. Переезд справочника с одного механизма на другой требует переноса записей, правки всех выборок и пересборки индексов - работы на день там, где выбор занял бы пять минут.

Типичные проблемы

Код проекта сломался после переименования записи.

Код опирается на название записи, а не на её отдельный код. Названия правит сотрудник, и это нормально.

Сотрудник не видит свой список.

Права на список не выданы: они задаются отдельно от прав на разделы сайта. Право на чтение и на правку выдают явно.

Список правки открывается по полминуты.

В списке десятки тысяч записей, и интерфейс на это не рассчитан. Для таких объёмов берут highload-блок.

В справочнике три похожие записи.

У списка нет ответственного, и записи заводит кто придётся. Хозяина справочника называют при его создании.

Поле добавили, а на сайте его нет.

Выборка на сайте запрашивает старый набор свойств. Новое поле добавляют и в список свойств выборки.

Частые вопросы

Чем список лучше инфоблока?

Тем, что поля и записи ведёт сотрудник без разработчика. Инфоблок нужен там, где важны разделы и права на элементы.

Как читать список из кода?

Обычной выборкой элементов инфоблока: список устроен на них. Отдельного API учить не нужно.

Когда переходить на highload-блок?

Когда записей становится больше нескольких тысяч. Интерфейс списка на таком объёме уже мешает.

Можно ли запустить процесс по записи списка?

Да, бизнес-процессы работают с элементами списка. Это одна из основных причин выбрать список.

Смежное

Первоисточник