Тридцать региональных редакторов, один сайт, одна админка — и рано или поздно кто-то из региона либо случайно опубликует страницу с ошибкой на всю сеть, либо отредактирует контент соседнего филиала, потому что не глядя открыл чужой раздел. На федеральных и мультирегиональных проектах это не гипотетический риск, а вопрос времени: чем больше редакторов работает в одной системе, тем выше цена одной неаккуратной правки.
Ниже — практический разбор того, как в 1С-Битрикс построить ролевую модель для десятков региональных редакторов: сколько нужно групп пользователей, как физически ограничить редактору доступ только его регионом, как устроить модерацию и как потом разобраться, кто и что изменил. Это обобщённый опыт наших проектов по разработке федеральных сайтов на 1С-Битрикс — конкретный пример такой сети мы разбирали в материале о запуске федерального сайта франчайзинговой сети.
Коротко
- Регион задаётся не отдельной группой пользователей, а правами на конкретный раздел инфоблока — иначе групп станет столько же, сколько регионов.
- Общие элементы (шаблон, шапка, юридические страницы) не должны быть доступны редакторам регионов вообще — только центру.
- Для страниц, которые видит вся сеть, нужна премодерация через статус «На согласовании»; для локального контента региона достаточно постмодерации.
- Обязательно включите историю изменений элементов — без неё разбор инцидента через полгода займёт часы вместо минут.
- Модель, построенная на правах к разделам, масштабируется без изменения структуры групп при росте сети.
Почему федеральный сайт — это не «ещё один» сайт с правами
На обычном корпоративном сайте с 2–3 редакторами вопрос разграничения прав решается почти интуитивно: одна группа «Редакторы», одна группа «Администраторы», и все всё видят — команда маленькая, доверие высокое, цена ошибки низкая. На федеральном сайте с представительствами в 30 городах и отдельным редактором в каждом филиале ситуация принципиально другая: люди из разных отделов, часто не знакомые друг с другом лично, работают в одной системе одновременно.
Здесь встречаются три задачи, которые в маленьком проекте просто не возникают. Первая — изоляция данных: редактор Новосибирска не должен видеть, а тем более редактировать раздел Казани. Вторая — защита общего ядра: шаблон, меню, юридические страницы и общие лендинги должны быть недоступны для правки из регионов в принципе. Третья — прослеживаемость: когда на сайте одного из городов появляется ошибка или недостоверная информация, нужно быстро понять, кто её внёс и когда, не поднимая всех 30 редакторов по тревоге.
Решить это на глазок, раздавая права «по ощущениям» в процессе работы, не получится — систему нужно спроектировать на старте, как и структуру инфоблоков. Здесь мы разбираем именно роли и права; если нужен более широкий взгляд на проектирование структуры контента — см. отдельный материал о проектировании структуры инфоблоков.
Три принципа ролевой модели для сети из 30+ регионов
Прежде чем раскладывать права по интерфейсу админки, полезно зафиксировать архитектурные принципы — они не дадут модели «расползтись» по мере роста сети.
- Роль отделена от региона. Группа пользователей описывает, что человеку разрешено делать (создавать, редактировать, публиковать), а где именно — определяют права на конкретный раздел, привязанные к пользователю отдельно. Так 30 регионов не превращаются в 30 групп.
- Минимум привилегий по умолчанию. Каждому редактору выдаётся ровно тот набор прав, который нужен для его задачи, ни больше. Расширять права проще, чем разбираться, что натворил человек с правами администратора «на всякий случай».
- Общее ядро закрыто от региона. Шаблон сайта, общие инфоблоки, настройки модулей и SEO-инфраструктура редактируются только центральной командой — независимо от того, насколько доверенный региональный редактор.
Эти три принципа звучат просто, но именно их нарушение — источник почти всех инцидентов на федеральных сайтах: кто-то расширил права «временно и забыл вернуть», кто-то завёл региону права на инфоблок целиком вместо конкретного раздела, кто-то дал доступ к шаблону «чтобы не дёргать разработчика по мелочи».
Группы пользователей: сколько нужно и по какому принципу
Соблазн завести отдельную группу на каждый регион («Редактор Новосибирска», «Редактор Казани» и так далее) понятен — так проще на старте. Но при 30 регионах это 30 групп, а при масштабировании до 80 — 80 групп, каждую из которых нужно вручную настраивать и поддерживать. Правильный подход — небольшой набор ролевых групп, где роль описывает функцию, а не географию.
| Группа | Кто это | Что может |
|---|---|---|
| Региональный редактор | Сотрудник филиала | Создавать и редактировать элементы в разделе своего региона |
| Региональный модератор | Руководитель филиала / маркетолог | То же + публикация контента региона без согласования с центром |
| Контент-менеджер центра | Сотрудник головного офиса | Правка общих разделов, шаблонов страниц, навигации |
| Модератор центра | Руководитель контента | Согласование контента, который выходит на всю сеть |
| Администратор | IT / разработчик | Полный доступ: структура, права, модули, интеграции |
Региональность каждому конкретному пользователю задаётся не выбором группы, а правами доступа, назначенными персонально на раздел инфоблока, — об этом подробнее в следующем разделе. Такая схема означает, что при найме нового редактора в 31-м регионе вы не создаёте новую группу, а заводите пользователя в существующую группу «Региональный редактор» и привязываете его к новому разделу.
Структура разделов и инфоблоков под региональность
Ролевая модель работает только поверх правильно спроектированной структуры контента. Для федерального сайта с региональными редакторами разумная схема — один инфоблок «Филиалы» (или «Региональный контент»), где каждому региону соответствует свой раздел верхнего уровня, а внутри него — подразделы под типы контента (новости региона, акции региона, вакансии региона).
- Один раздел — один регион. Прямое соответствие «раздел = филиал» упрощает как права, так и навигацию по сайту.
- Общий контент — отдельный инфоблок. Общие для всей сети новости, акции и страницы живут в другом инфоблоке (или в корневых разделах того же инфоблока), недоступном региональным редакторам.
- Свойства без региональной привязки — на уровне инфоблока. Общие для всех регионов типы данных (например, список категорий услуг) стоит держать в справочнике или highload-блоке, а не дублировать в каждом региональном разделе.
Если структура смешана — общий и региональный контент в одном разделе без чёткого разделения — построить корректные права поверх неё будет либо невозможно, либо придётся ограничивать доступ на уровне отдельных элементов вручную, что не масштабируется на десятки редакторов.
Права на разделы: как физически изолировать регион
Технически изоляция строится на правах доступа к конкретному разделу инфоблока. В 1С-Битрикс у каждого раздела можно задать индивидуальные права — отдельно от общих прав группы на инфоблок целиком. Логика такая: группа «Региональный редактор» получает право «Нет доступа» на инфоблок в целом, а затем каждому конкретному пользователю точечно выдаётся право «Изменение» на раздел именно его региона.
Права наследуются вниз по дереву разделов: если у редактора есть право на раздел «Новосибирск», он автоматически получает такое же право на все подразделы внутри («Новости», «Акции», «Вакансии»), но не получает его на соседний раздел «Казань». Это ключевое свойство, на котором держится вся модель — не нужно вручную прописывать права на каждый подраздел, достаточно один раз настроить их на корневом разделе региона.
- Создайте раздел на регион. В инфоблоке «Филиалы» заведите раздел для каждого города с понятным символьным кодом (
novosibirsk,kazan). - Снимите права по умолчанию. В настройках группы «Региональный редактор» на уровне инфоблока установите «Доступ запрещён» — без явного разрешения на раздел группа ничего не увидит.
- Назначьте индивидуальные права на раздел. Откройте раздел региона → вкладка «Права доступа» → добавьте конкретного пользователя (или подгруппу) с уровнем «Изменение» (без права «Удаление», если не требуется).
- Проверьте наследование. Убедитесь, что подразделы внутри региона унаследовали права — специально ничего дополнительно настраивать не нужно.
- Протестируйте под учёткой редактора. Зайдите в админку под тестовым пользователем региона и убедитесь, что чужие разделы не отображаются в дереве и не открываются по прямой ссылке.
Общие элементы: шаблон, шапка, единые страницы
Отдельная категория риска — не контент региона, а общие элементы сайта: шаблон, компонент меню, футер с юридическими реквизитами, общие лендинги и промо-страницы, которые видит вся сеть одновременно. Их не нужно вообще пускать в тот же контур прав, что и региональный контент.
Практическое правило: правка шаблонов страниц, файлов компонентов и структурных элементов навигации доступна только группам «Контент-менеджер центра» и «Администратор». Региональный редактор физически не имеет доступа к разделу «Управление структурой» и к визуальному редактору страниц шаблона — у него в меню админки эти пункты просто не отображаются, потому что права на соответствующие модули не выданы.
Модерация и статусы согласования контента
Не весь региональный контент одинаково рискован. Новость о локальной акции филиала, которую увидят только посетители страницы этого региона, можно публиковать сразу — постмодерация с оповещением центра снижает риск до приемлемого уровня. А вот страница, которая появляется в общем списке новостей всей сети, на главной или в общих виджетах, требует премодерации: ошибка на ней видна не одному региону, а всем посетителям сайта.
Технически премодерация реализуется через статус активности и дополнительное свойство «Статус согласования» у элемента: региональный редактор сохраняет материал со статусом «На согласовании» (элемент при этом не активен и не выводится на сайте), модератор центра видит очередь таких элементов в специальном фильтре списка и переводит их в статус «Опубликовано», делая элемент активным.
- Постмодерация — для локального, низкорискового контента региона (новости филиала, изменение часов работы).
- Премодерация — для контента, который выходит за пределы региона (общие акции, изменения в юридических документах, промо на главной).
- Автоматическое оповещение — модератор получает уведомление (на e-mail или в CRM-задачу через Битрикс24) о новых элементах в очереди согласования, чтобы не проверять список вручную.
Журнал действий и история изменений
Права ограничивают, что человек может сделать, но не отвечают на вопрос «что уже произошло». На федеральном сайте с 30 активными редакторами рано или поздно возникнет ситуация: на сайте региона нашли ошибку — устаревшую цену, неверный номер телефона, некорректный текст — и непонятно, когда и кем она появилась. Без журнала действий разбор такого инцидента превращается в опрос всех причастных.
Два штатных механизма закрывают эту задачу. Первый — история изменений элементов инфоблока (версионность): включается в настройках инфоблока, и по каждому элементу можно посмотреть все сохранённые версии с указанием автора и времени правки, а при необходимости — откатиться к предыдущей версии. Второй — журнал событий (лог действий пользователей на уровне ядра), который фиксирует факты входа в систему, изменения прав, удаления — то есть более широкий контур, чем просто контент.
Как это выглядит в админке 1С-Битрикс
Права на раздел настраиваются на вкладке «Права доступа» раздела инфоблока — рядом с обычными полями названия и сортировки. Схематично это выглядит так:
Внедрение ролевой модели пошагово
- Зафиксируйте список ролей. Согласуйте с заказчиком, какие роли реально нужны — обычно 4–6, не больше (см. таблицу выше).
- Спроектируйте структуру разделов. Один регион — один корневой раздел, общий контент — отдельно.
- Создайте группы пользователей. По одной группе на роль, без привязки к географии.
- Настройте права по умолчанию. На уровне инфоблока — «Доступ запрещён» для региональных групп.
- Заведите пользователей и назначьте точечные права. Каждому редактору — право на раздел его региона.
- Настройте статусы согласования. Для контента, выходящего на всю сеть.
- Включите версионность и журнал событий. На всех инфоблоках с региональным контентом.
- Проведите тестовый прогон. Под учётками двух разных регионов убедитесь во взаимной изоляции.
Масштабирование: от 30 к 80+ регионам
Главное преимущество модели «роль отделена от региона» — она не меняется при росте сети. Добавление 31-го, 50-го или 80-го региона — это создание нового раздела и назначение прав новому пользователю, а не пересмотр структуры групп. Если модель изначально построена как «группа на регион», рост сети линейно увеличивает административную нагрузку и рано или поздно упирается в предел, который команда поддержки уже не может обслуживать вручную.
При росте сети стоит заранее продумать два момента. Первый — производительность списков в админке: когда элементов десятки тысяч, полезно добавить фильтр по ответственному пользователю или региону в списке инфоблока, чтобы редактор не листал общий список. Второй — регламент модерации: если один модератор центра физически не успевает согласовывать поток материалов от 80 регионов, роль стоит распределить по направлениям (например, отдельный модератор на группу федеральных округов), сохранив при этом единый набор ролей и прав.
Частые ошибки при разграничении прав
- Заводят отдельную группу пользователей на каждый регион вместо прав на раздел — структура быстро становится неуправляемой.
- Дают региональной группе права на инфоблок целиком «для простоты», рассчитывая на добросовестность редакторов, а не на техническое ограничение.
- Забывают закрыть доступ к общим инфоблокам (баннеры, юридические страницы, шаблон) — редактор региона получает возможность повлиять на всю сеть.
- Не включают версионность до первого инцидента — а затем не могут восстановить историю задним числом.
- Не тестируют права под реальной учёткой редактора перед запуском — расхождения обнаруживаются уже в бою.
- Не разделяют пре- и постмодерацию — либо всё требует ручного согласования и тормозит работу региона, либо ничего не проверяется и риск ошибок растёт.
- Смешивают общий и региональный контент в одном разделе инфоблока — на такой структуре корректные права выстроить почти невозможно.
Чек-лист готовности ролевой модели
- Роли зафиксированы. 4–6 групп, каждая описывает функцию, а не географию.
- Структура разделов region-first. Один регион — один корневой раздел с подразделами.
- Права по умолчанию — «Доступ запрещён». На инфоблоке для региональных групп, точечные права — на конкретных пользователей.
- Общее ядро изолировано. Шаблон, навигация, юридические страницы недоступны региональным редакторам.
- Модерация настроена. Статус «На согласовании» для контента, выходящего за пределы региона.
- Версионность включена. На всех инфоблоках с региональным контентом, с самого запуска.
- Проведён тестовый прогон. Под учётками минимум двух разных регионов, изоляция подтверждена.
- Регламент модерации описан. Кто, в какой срок и по какому критерию согласует контент центра.
Вывод
Ролевая модель федерального сайта держится не на количестве групп пользователей, а на правильном разделении понятий «роль» и «регион»: роль — это группа с фиксированным набором прав, регион — это индивидуальная привязка пользователя к разделу инфоблока. Вместе с закрытым от регионов общим ядром, продуманной модерацией и включённой версионностью такая модель одинаково хорошо работает и на 30, и на 80 региональных редакторах, не требуя пересмотра при росте сети.
