Битрикс права доступа настраиваю на каждом проекте, где над сайтом или каталогом работает больше одного человека: администратор, контент-менеджер, разработчик подрядчика. Без разделения по группам первый же новый сотрудник получает доступ либо совсем ко всему, либо к пустой админке без единого пункта меню, и потом полдня разбираешься, что он там нажал и почему. Ниже разбираю, как в 1С-Битрикс устроены группы пользователей, уровни доступа к модулям, права на разделы инфоблоков с наследованием, ограничение папок сайта через .access.php и чем от всего этого отличаются роли в Битрикс24.
Как устроена система прав: группы пользователей вместо ролей
В «1С-Битрикс: Управление сайтом» нет отдельной сущности «роль», которую можно гибко клонировать под задачу, как в некоторых других системах. Роль здесь по сути и есть группа пользователей: создаёшь группу «Контент-менеджеры», «Модераторы отзывов» или «Бухгалтерия», выставляешь ей права на нужные модули и разделы, а потом добавляешь туда сотрудников. Один человек может состоять сразу в нескольких группах, и на практике эффективные права складываются по наиболее широкому уровню доступа из всех групп пользователя, поэтому неаккуратное добавление в «лишнюю» группу почти всегда расширяет доступ, а не ограничивает его.
Группы настраиваются в административной панели, в разделе «Пользователи» - «Группы пользователей». Для каждой группы задаётся:
- список модулей и уровень доступа к каждому;
- права на инфоблоки, если они используются на сайте;
- при необходимости - ограничение на конкретные разделы сайта через файлы .access.php.
На небольшом сайте с одним админом и парой контент-менеджеров хватает трёх-четырёх групп. На корпоративном портале с отделами, филиалами и внешними подрядчиками я обычно завожу отдельную группу под каждую функциональную роль, даже если набор прав у них почти одинаковый, просто чтобы потом было понятно из одного списка, кто за что отвечает.
Уровни доступа к модулям административной панели
На вкладке «Права доступа» группы виден список всех установленных модулей: главный модуль, информационные блоки, интернет-магазин, реклама, статистика и так далее. Для каждого модуля отдельно выбирается уровень: от «нет доступа», когда пункт меню в админке вообще не показывается, до «полного доступа» со всеми операциями. Между ними лежат промежуточные градации, обычно это доступ на чтение и доступ на изменение, а у некоторых модулей есть собственные дополнительные уровни под их специфику, например у интернет-магазина отдельно можно открыть доступ к заказам без права их удалять.
На практике я почти никогда не даю группе «Полный доступ» ко всем модулям сразу, даже если человек формально администратор проекта. Обычно разношу так:
- контент-менеджерам - доступ на изменение к информационным блокам и файлам, без доступа к техническим настройкам ядра;
- бухгалтерии или менеджерам по продажам - доступ на чтение или изменение только к модулю интернет-магазина, без прав на каталог и инфоблоки;
- подрядчику на аутсорсе - временную группу с доступом только к тем модулям, которые нужны под конкретную задачу, права на которую снимаю сразу после сдачи работы.
Если после обновления модуля или установки нового решения из маркетплейса сотрудник вдруг не видит пункт меню, который раньше был, в большинстве случаев дело не в баге, а в том, что новый модуль подключился с правами «Нет доступа» для всех групп кроме администраторов, и на него просто забыли выставить уровень доступа руками.
Права доступа к разделам инфоблоков и наследование
Инфоблоки в Битриксе, будь то каталог товаров, новости или база знаний, имеют собственную вкладку прав, отдельную от прав на модуль «Информационные блоки» в целом. Здесь можно дать группе доступ ко всему инфоблоку целиком: от «нет доступа» через «чтение» и «изменение собственных элементов» до «полного доступа» с правом менять права других групп.
Когда инфоблок при создании помечен флагом доступа по разделам, права можно выставлять точечно, для каждого раздела каталога отдельно, а не только на весь инфоблок сразу. Это реально нужно на многобрендовом магазине, где менеджер бренда A не должен даже видеть карточки бренда B, или на корпоративной базе знаний, разбитой по отделам.
Наследование прав от родительского раздела
Если для раздела права не заданы явно, он наследует их от родителя, и так по цепочке до корня инфоблока. Стоит один раз выставить права на подраздел вручную, и дальше вся ветка ниже него будет считать именно этот подраздел новой точкой отсчёта, а не общие настройки инфоблока. Именно здесь чаще всего теряют доступ: контент-менеджер годами спокойно редактировал каталог, кто-то один раз закрыл права на один подраздел под другую задачу, и вся ветка под ним внезапно оказалась недоступна остальной команде.
Когда включать доступ по разделам
Включать точечные права по разделам лучше сразу на этапе проектирования структуры, а не когда каталог уже разросся. На инфоблоке, где счёт разделов идёт на сотни, пересчёт индекса прав после включения этой опции занимает заметное время, в моей практике на каталоге примерно из 500 разделов это заняло около 10 минут, и в процессе пересчёта часть контент-менеджеров временно теряла доступ к разделам без явно выставленных прав. Если сайт уже в работе и меняешь права по разделам на живую, лучше делать это в нерабочие часы и заранее предупредить контент-отдел.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Доступ к файлам и папкам публичной части сайта
Права модулей и инфоблоков касаются административной панели, а видимость страниц на самом сайте для посетителей и авторизованных пользователей регулируется отдельно, через файлы .access.php. Настраиваются они в разделе «Контент» - «Файлы и папки»: выбираешь папку, задаёшь права доступа и указываешь, какой группе какой уровень доступен, от «нет доступа» до «полного доступа». Битрикс сам создаёт в папке файл .access.php с этими настройками, и ядро проверяет его при каждом запросе, который проходит через index.php.
Это удобно для закрытых разделов вроде личного кабинета партнёра, документов для дилеров или тестовой версии нового раздела, которую пока не должны видеть все. Важный нюанс: ограничение через .access.php работает только для запросов, которые обрабатывает ядро Битрикса. Если файл в этой папке отдаётся веб-сервером напрямую, например статичный документ по прямой ссылке без прохода через компонент, .access.php его не защитит, и для таких файлов нужны либо права на уровне веб-сервера, либо хранение вне публичной директории с отдачей через отдельный скрипт-обработчик.
Роли в Битрикс24: другая модель прав
В Битрикс24 для CRM есть настоящие роли доступа: их создают в настройках CRM, каждой роли задают права на лиды, сделки, компании и другие сущности с масштабом «только свои», «свои и подчинённых» или «все записи», и одну роль можно назначить сразу многим сотрудникам без привязки к их группе в классическом смысле. Это ближе к привычному ролевому доступу, чем система групп в «Управлении сайтом».
Путать эти две системы не стоит: роли CRM работают внутри модуля CRM и не распространяются на инфоблоки, каталог интернет-магазина или административные модули классической части портала. Если на портале Битрикс24 используется интернет-магазин или сложная структура инфоблоков, права на них всё равно настраиваются через группы пользователей и права разделов, как описано выше, а роли CRM решают только задачи внутри самого CRM.
Типичные ошибки при настройке доступа
За несколько лет работы с правами Битрикса чаще всего натыкаюсь на одни и те же грабли:
- Пользователь состоит в нескольких группах, и одна из них шире, чем задумано. Проверять права нужно с учётом всех групп сотрудника, а не только той, в которую его добавили последней.
- После установки нового модуля или обновления решения из маркетплейса никто не выставил права для рабочих групп, и модуль по факту недоступен всем, кроме администраторов, хотя выглядит это как сломанный функционал.
- Включили доступ по разделам на живом каталоге без предупреждения контент-отдела, и часть менеджеров временно теряет видимость разделов без явно выставленных прав.
- Права на модуль в админке путают с правами на страницы сайта через .access.php: думают, что закрыли раздел от гостей, хотя на самом деле ограничили только вкладку в панели управления.
- Проверяют права по таблице уровней в документации, а не через живого тестового пользователя в нужной группе. Я обычно завожу отдельного тестового пользователя на каждую крупную группу и логинюсь под ним, чтобы увидеть админку и сайт ровно так, как их увидит реальный сотрудник.
Если структура прав на проекте уже разрослась настолько, что никто в команде не может внятно объяснить, кто и что видит, беру консультацию по настройке доступа и разбираю дерево групп и разделов с нуля, а не пытаюсь точечно латать симптомы.
Частые вопросы
Как узнать, в каких группах состоит пользователь?
Открываю карточку пользователя в разделе «Пользователи» - «Список пользователей», на вкладке групп видно все группы, в которые он включён, включая системные вроде «Все пользователи (авторизованные)». Эффективные права - это объединение прав всех этих групп, поэтому смотреть нужно на весь список, а не на одну ожидаемую группу.
Почему у сотрудника пропал доступ после обновления модуля?
Чаще всего новый или обновлённый модуль подключается с правами «Нет доступа» для всех групп кроме администраторов, а права на него просто не выставлены руками. Проверяю вкладку «Права доступа» нужной группы и добавляю модуль с подходящим уровнем.
Можно ли дать доступ только к одному разделу каталога, а не ко всему инфоблоку?
Да, если у инфоблока включён доступ по разделам. Тогда права настраиваются для каждого раздела отдельно, а разделы без явных настроек наследуют права от родителя. Если этот флаг при создании инфоблока не включали, права можно выставить только на весь инфоблок целиком, а включение доступа по разделам на уже заполненном каталоге требует пересчёта индекса прав.
Как ограничить доступ к папке на сайте для конкретной группы?
В разделе «Контент» - «Файлы и папки» выбираю нужную папку и задаю права доступа по группам, Битрикс создаёт файл .access.php с этими настройками. Работает это только для запросов, которые обрабатывает ядро Битрикса через index.php, для файлов, отдаваемых веб-сервером напрямую, нужен другой механизм защиты.