Администрирование · 10 мин
Атомарная роль в 1С: что это и как правильно её использовать
Атомарная роль в 1С — это роль, дающая права на один объект метаданных. Разбираем принцип, настройку, объединение в профили и типичные ошибки.
Атомарная роль в 1С — это роль, которая предоставляет права только на один объект метаданных или на одну узкую операцию, не смешивая доступ к разным областям системы. Например, отдельная роль «Чтение контрагентов» и отдельная — «Изменение контрагентов», вместо одной большой роли «Работа со справочниками». Термин происходит от слова «атом»: роль неделима, её нельзя разбить на более мелкие функциональные части без потери смысла.
Такой подход стал фактическим стандартом при разработке конфигураций и настройке прав доступа. В типовых решениях «1С:Библиотека стандартных подсистем» права организованы именно через наборы мелких ролей, которые затем группируются в профили групп доступа. Администратор не редактирует роли пользователей напрямую, а собирает нужный уровень доступа из готовых «кирпичиков».
Зачем это нужно на практике: когда права разложены по атомарным ролям, проще выдать сотруднику ровно тот доступ, который требуется для его работы, не открывая лишнего. Это снижает риск случайного изменения или удаления данных, упрощает аудит прав и ускоряет поиск причины, когда у пользователя «что-то не открывается».
Что такое атомарная роль и чем она отличается от обычной
Обычная (составная) роль в конфигураторе может включать права на десятки объектов: справочники, документы, регистры, отчёты. Пока система небольшая, это удобно. Но как только появляются пользователи с разными задачами, монолитные роли начинают мешать: кассиру нужны только продажи, а роль «Менеджер» заодно открывает закупки и склады.
Атомарная роль решает эту проблему дроблением. Каждая роль отвечает за один объект и, как правило, за один тип операции: чтение, добавление, изменение, проведение, удаление. Пользователь получает не одну «большую» роль, а набор мелких, сумма которых точно соответствует его обязанностям.
Важно понимать, что атомарность — это не свойство платформы, а принцип проектирования. Платформа 1С не запрещает делать широкие роли; атомарность — договорённость разработчиков и администраторов о том, как структурировать права, чтобы системой было удобно управлять.
Как устроены права в типовых конфигурациях
В конфигурациях на базе БСП (1С:Бухгалтерия, Управление торговлей, ЗУП и другие) права организованы в три уровня. Нижний уровень — атомарные роли, зашитые в конфигурацию. Средний — профили групп доступа, которые администратор создаёт в режиме предприятия и наполняет ролями. Верхний — группы доступа, в которые включаются конкретные пользователи.
На уровне конфигуратора атомарные роли часто имеют говорящие имена: «ЧтениеНоменклатуры», «ДобавлениеИзменениеРеализацияТоваровУслуг», «ЧтениеДанныхРегламентированногоУчета». По имени уже понятно, что роль делает, и не нужно открывать её состав, чтобы оценить последствия выдачи.
Как создать атомарную роль в конфигураторе
Если вы дорабатываете конфигурацию или добавляете собственные объекты, атомарные роли для них создаются вручную. Порядок действий стандартный и не требует программирования — только аккуратная работа в дереве конфигурации.
- 1Откройте конфигуратор, ветку «Общие» → «Роли» и добавьте новую роль с понятным именем, например «ЧтениеВнутреннихЗаказов».
- 2В окне настройки прав найдите свой объект метаданных и отметьте только нужные права: чтение — для просмотра, добавление и изменение — для редактирования.
- 3Снимите права на все остальные объекты — роль должна остаться атомарной.
- 4Проверьте права на связанные объекты: для документа часто требуется чтение используемых справочников, иначе форма не откроется.
- 5Обновите конфигурацию базы данных и добавьте роль в нужный профиль групп доступа.
- 6Проверьте доступ под тестовым пользователем: объект открывается, лишние разделы недоступны.
Тонкий момент — права на связанные объекты. Если документ содержит ссылку на справочник «Склады», а у пользователя нет права чтения этого справочника, форма документа может открываться с ошибками или пустыми полями. Поэтому роли чтения базовых справочников обычно выдаются широкому кругу пользователей как вспомогательные.
Атомарные роли и ограничение доступа на уровне записей (RLS)
Атомарная роль определяет, к каким объектам пользователь имеет доступ в принципе. Механизм RLS (Record Level Security) уточняет, к каким именно записям внутри объекта. Например, роль даёт право чтения документов «Реализация товаров и услуг», а RLS-шаблон ограничивает выборку только документами конкретной организации или склада.
Эти механизмы работают вместе: сначала платформа проверяет право на объект, затем применяет шаблон ограничения. Поэтому при диагностике проблем с доступом нужно проверять оба уровня. Частая ситуация: роль выдана корректно, но пользователь «не видит» документы, потому что в профиле включено ограничение по группам доступа контрагентов, а нужный контрагент ни в одну разрешённую группу не входит.
Как собрать профиль доступа из атомарных ролей
Профиль групп доступа создаётся в разделе администрирования (в типовых конфигурациях это «Настройки прав и пользователей» → «Профили групп доступа»). Внутри профиля вы отмечаете разрешённые роли — по сути, собираете должность из атомарных «кирпичей». Затем создаётся группа доступа с этим профилем, и в неё включаются пользователи.
Сравнение вариантов
Подходит для стандартных должностей: кассир, менеджер по продажам, бухгалтер. Быстро, но может включать лишние права или не покрывать специфику.
Оптимально для большинства случаев: копируете близкий по задачам профиль и добавляете или снимаете отдельные роли. Типовой профиль при этом остаётся нетронутым.
Нужен для нестандартных ролей вроде внешнего аудитора или интеграционного пользователя. Требует аккуратного подбора ролей чтения связанных объектов, иначе формы не будут работать.
Практическое правило: не редактируйте поставляемые типовые профили. Создайте копию, измените её и используйте свою версию. Тогда при обновлении конфигурации типовые профили обновятся штатно, а ваши доработки не потеряются и не вступят в конфликт с механизмом обновления.
Диагностика проблем с доступом
Когда пользователь сообщает «нет прав», причина почти всегда в одном из трёх мест: не хватает атомарной роли в профиле, срабатывает RLS-ограничение или пользователь не включён в нужную группу доступа. Проверять стоит именно в этом порядке — от простого к сложному.
Как проверить результат
Пользователь есть в списке участников группы
Группа пуста или пользователь в другой группе
Нужная роль отмечена в списке разрешённых ролей профиля
Роль отсутствует — объект не откроется вовсе
Записи видны с учётом заданных ограничений по организациям, складам, контрагентам
Объект открывается, но список пуст или часть записей не видна
Форма открывается, поля заполнены, кнопки активны
Пустые поля ссылок или недоступные кнопки — не хватает ролей чтения связанных объектов
Полезный приём — отчёт «Анализ прав доступа» (в типовых конфигурациях доступен в настройках прав). Он показывает, какие роли и через какие профили есть у конкретного пользователя, и позволяет быстро сравнить его набор прав с эталонным сотрудником, у которого всё работает.
Типичные ошибки при работе с ролями
Отдельно стоит упомянуть копирование пользователей «по образцу» без анализа. Когда нового сотрудника добавляют в те же группы доступа, что и его предшественника, вместе с нужными правами он получает и накопленные годами избыточные. Правильнее собирать доступ от должности, а не от конкретного человека.
Ведите простой реестр: какой профиль каким должностям соответствует и почему в него добавлены нестандартные роли. Когда сотрудник, настраивавший права, увольняется, такой документ экономит дни на восстановление логики доступа.
Частые вопросы об атомарных ролях в 1С
Атомарная роль — это встроенный объект платформы 1С?
Нет. Платформа поддерживает только механизм ролей как таковой. Атомарность — это принцип проектирования: разработчик конфигурации сознательно делает каждую роль узкой, отвечающей за один объект или операцию. Проверить «атомарность» можно только по составу прав конкретной роли.
Можно ли назначать атомарные роли пользователю напрямую, минуя профили?
Технически в конфигураторе можно отметить роли в свойствах пользователя, но в типовых конфигурациях с подсистемой управления доступом это не рекомендуется: механизм профилей может перезаписывать состав ролей, и настройка станет непредсказуемой. Правильный путь — включить роль в профиль групп доступа.
Сколько атомарных ролей может быть у одного пользователя?
Жёсткого практического ограничения для администратора нет: у пользователя типовой конфигурации через профили обычно задействованы десятки ролей. Важнее не количество, а понятность структуры — чтобы по составу профиля было ясно, какие задачи выполняет сотрудник.
Чем атомарная роль отличается от RLS?
Роль отвечает на вопрос «к каким объектам есть доступ», RLS — «к каким записям внутри этих объектов». Сначала платформа проверяет право на объект по роли, затем применяет ограничение на уровне записей. Для полноценной настройки доступа обычно нужны оба механизма.
Почему после добавления роли в профиль у пользователя ничего не изменилось?
Чаще всего пользователь не включён в группу доступа с этим профилем, либо он не перезапустил сеанс — права подхватываются при новом входе. Реже причина в том, что в профиле роль отмечена, но для объекта срабатывает RLS-ограничение, и данные просто не попадают в выборку.
Нужно ли создавать атомарные роли для собственных доработок?
Да. Если вы добавили в конфигурацию новый документ или регистр, создайте для него отдельные роли чтения и изменения, а не расширяйте существующие широкие роли. Так ваши доработки впишутся в типовую схему управления доступом и не создадут проблем при обновлениях.
Что важно запомнить
Атомарная роль — это узкая роль на один объект или операцию, из которых собираются профили доступа. Работайте через профили групп доступа, копируйте типовые профили вместо их правки, не забывайте про роли чтения связанных объектов и проверяйте результат под тестовой учётной записью, а не под администратором.