Битрикс пользователи: группы, права и свои поля профиля

Каждый проект на Битриксе, где кроме витрины появляется личный кабинет, партнёрский раздел или закрытый прайс, упирается в один и тот же вопрос: как управлять пользователями так, чтобы не превратить админку в помойку из полного доступа для всех. Я регулярно донастраиваю права и поля профиля на чужих проектах, где изначально всем сотрудникам выдали группу «Администраторы», а потом удивляются, почему менеджер по продажам может удалить инфоблок с товарами. Дальше по порядку: как устроены пользователи в Битриксе на уровне групп и прав, как добавить свои поля в профиль и куда смотреть, если синхронизация с CRM ломает импорт.

Как устроены пользователи в Битриксе на уровне ядра

Каждый пользователь в системе это запись в таблице b_user, за работу с которой отвечает класс CUser. Кроме стандартных полей вроде логина, email и ФИО у записи есть привязка к одной или нескольким группам через таблицу b_user_group. Права считаются не для конкретного человека, а для группы: если пользователь состоит сразу в двух группах, ему достаются права по максимальному значению из обеих. Это первое, что стоит проверить, если доступ ведёт себя неожиданно, обычно проблема в том, что человека забыли убрать из старой группы при переводе в новую.

Отдельно стоит развести понятия: группа пользователей на сайте и роль в Битрикс24 это разные вещи из разных продуктов. Если сайт на 1С-Битрикс интегрирован с Битрикс24 через REST, права на сайте и права в CRM настраиваются независимо друг от друга.

Группы пользователей и права доступа: где настраивать

Группы создаются в разделе Настройки -> Пользователи -> Группы пользователей. По умолчанию в системе две группы, и удалить их нельзя: «Все пользователи (в том числе неавторизованные)», куда попадают все посетители сайта, и «Администраторы» с полным доступом к управлению сайтом. Под свои задачи обычно добавляю ещё «Контент-менеджеры», «Партнёры B2B» или похожие.

На вкладке «Доступ» у каждой группы настраиваются уровни прав доступа к модулям системы, причём набор уровней зависит от модуля: например, для «Управления структурой» это «Редактирование файлов и папок». Для инфоблоков права можно уточнить ещё точнее, зайдя в настройки самого инфоблока на вкладку «Доступ» и указав уровень для группы не на весь модуль, а на конкретный инфоблок или даже раздел внутри него.

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

Свои поля профиля пользователя: когда и как добавлять

Свои поля добавляются на странице Настройки -> Настройки продукта -> Пользовательские поля, кнопка «Добавить». Второй штатный способ - ссылка «Добавить пользовательское свойство» прямо в форме редактирования пользователя. Код поля принято начинать с UF_, дальше система сама подставит его в форму регистрации и в профиль на публичной части, если она использует стандартный компонент вывода профиля без переопределения шаблона.

Из типов полей чаще всего беру: строка, число, да/нет, список с вариантами, файл, дата или дата и время, привязка к элементам справочника через HL-блок. На практике добавлял UF_BIRTHDAY для программы лояльности, чтобы отправлять промо ко дню рождения, UF_COMPANY и UF_INN в B2B личном кабинете, чтобы не спрашивать реквизиты при каждом заказе, и файловое поле для скана документа в партнёрской программе, где нужна верификация перед первой выплатой.

Если форма профиля на сайте кастомная и не берёт поля из стандартного компонента, новое UF-поле в вёрстке само не появится, его нужно добавить в шаблон отдельно. Читать и писать значение поля из кода можно через обычный CUser:

<?php
$rsUser = CUser::GetByID($USER->GetID());
$arUser = $rsUser->Fetch();
echo $arUser["UF_COMPANY"];

$user = new CUser;
$fields = array(
    "UF_COMPANY" => "ООО Ромашка",
);
$user->Update($USER->GetID(), $fields);
?>

Права на модули и разделы административной панели

Кроме прав на контент есть права на сами разделы админки. Группе можно дать доступ только к нужным модулям, например «Информационные блоки» и «Интернет-магазин», без модуля «Пользователи» и без «Настроек» - тогда пункт меню с группами и правами человек просто не увидит в списке.

Форма группы состоит из трёх вкладок: «Параметры», «Безопасность» и «Доступ». Привязка к IP лежит на «Безопасности» и запрещает не вход, а использование сессии и сохранённой авторизации с чужого адреса: поля «Маска сети для привязки сессии» и «Маска сети для привязки сохраненной авторизации». Это помогает для «Партнёров» или «Бухгалтерии», если они всегда заходят с одного офисного адреса. Если матрица прав получается сложной, а групп в проекте много, обычно быстрее сразу обсудить структуру на консультации по настройке прав доступа, чем потом разгребать, кто и почему видит лишнее.

Импорт и синхронизация пользователей с CRM

Частый сценарий: у клиента есть CRM, будь то Битрикс24, amoCRM или самописная система, и при регистрации на сайте контакт нужно продублировать туда. Для этого в модуле «Пользователи» есть события OnBeforeUserAdd, если нужно провалидировать данные до создания записи, и OnAfterUserAdd, чтобы отправить готовый контакт дальше уже после успешной регистрации.

<?php
AddEventHandler("main", "OnAfterUserAdd", "syncUserToCrm");

function syncUserToCrm($arFields)
{
    $data = array(
        "NAME"  => $arFields["NAME"],
        "EMAIL" => $arFields["EMAIL"],
        "PHONE" => $arFields["PERSONAL_PHONE"],
    );

    $ch = curl_init("https://your-crm.example.com/api/contacts");
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_exec($ch);
    curl_close($ch);
}
?>

Если контакты уходят во внешнюю систему, держите её на серверах в РФ - выгружать персональные данные пользователей в зарубежные облачные таблицы нельзя, это прямое требование локализации по 152-ФЗ.

При переносе базы со старого сайта обычный csv-импорт через админку тянет основные поля и группы, но не всегда подхватывает кастомные UF-поля и историю входов. Такой перенос надёжнее делать отдельным скриптом через CUser::Add с явной передачей всех значений, включая UF-поля, и с проверкой, что группы на новом сайте называются и весят так же, как на старом.

Частые ошибки при настройке прав

• всем сотрудникам выдают группу «Администраторы» вместо точечных прав, а потом менеджер случайно чистит рабочий каталог товаров;
• права тестируют только под своей учёткой с полным доступом, а не под живым пользователем нужной группы;
• забывают закрыть от группы «Все пользователи» разделы, которые должны быть видны только авторизованным;
• хранят чувствительные данные вроде сканов документов в обычных UF-полях без ограничения прав на просмотр самого поля;
• при переносе пользователей забывают перенести привязку к группам, и все попадают в группу по умолчанию без нужных прав.

1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.

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

Как ограничить доступ пользователей к разделу сайта в Битриксе?

Создайте отдельную группу под этот раздел, привяжите к ней нужных пользователей и на вкладке «Доступ» в настройках инфоблока или раздела выставьте для неё уровень «Чтение» или «Изменение», а для группы «Все пользователи» на этот же раздел поставьте «Запрещён».

Можно ли добавить пользователю несколько своих полей без правки шаблона?

Да, поля добавляются через Настройки -> Настройки продукта -> Пользовательские поля, и стандартные компоненты профиля и регистрации подхватывают их автоматически. Правка шаблона нужна, только если форма профиля переопределена под дизайн и не использует стандартный вывод полей через компонент.

Как перенести пользователей на новый сайт вместе с их правами?

Стандартный экспорт и импорт через админку переносит основные поля и группы, но не всегда переносит UF-поля и историю входов. Надёжнее писать перенос через CUser::Add и CUser::Update с явным маппингом всех полей, включая кастомные, и заранее свериться, что группы на новом сайте совпадают со старыми по названию и по правам.

Чем группа пользователей в 1С-Битрикс отличается от роли в Битрикс24?

Группа пользователей это сущность модуля «Пользователи» на сайте, она управляет доступом к разделам и модулям самого сайта. Роль в Битрикс24 живёт в отдельном продукте и системе CRM, отвечает за доступ к сделкам, лидам и отчётам внутри портала. Это две независимые системы прав, которые при интеграции через REST приходится синхронизировать вручную под конкретную задачу.