Администрирование · 11 мин
Как сравнить две роли в 1С: рабочие способы и пошаговые инструкции
Как сравнить две роли в 1С: штатные средства конфигуратора, сравнение конфигураций, обработки и выгрузка в XML. Пошаговые инструкции, риски и FAQ.
Сравнение ролей — типовая задача при аудите прав доступа, переносе настроек между конфигурациями и поиске причин, почему у двух пользователей с «одинаковыми» ролями разный доступ к документам или отчётам. Проблема в том, что в платформе 1С нет отдельной кнопки «сравнить две роли», поэтому приходится использовать обходные, но вполне рабочие методы.
Выбор способа зависит от того, где находятся роли: в одной конфигурации, в разных конфигурациях или в уже развёрнутых информационных базах. Также важно, что именно нужно сравнить — состав прав на объекты метаданных, шаблоны ограничения доступа к данным (RLS) или фактический доступ пользователей, которым эти роли назначены.
Ниже разобраны основные подходы: штатное сравнение конфигураций, выгрузка ролей в XML и сравнение файлов, сторонние обработки, а также проверка результата через фактические права пользователей. Каждый метод имеет свои ограничения, о которых нужно знать заранее.
Что именно нужно сравнивать в ролях
Роль в 1С — это не просто флажок, а набор прав на каждый объект метаданных: чтение, добавление, изменение, удаление, просмотр, интерактивные операции, а также права на реквизиты, табличные части и команды. Кроме того, роль может содержать шаблоны ограничения доступа к данным (RLS), которые дополнительно фильтруют записи на уровне строк.
Поэтому «сравнить роли» может означать разное: сопоставить состав прав на объекты, найти различия в RLS-шаблонах или понять, чем фактически отличается поведение системы для пользователей с этими ролями. Перед началом работы сформулируйте задачу точно — от этого зависит выбор инструмента.
Способ 1. Сравнение конфигураций в конфигураторе
Если две роли находятся в разных конфигурациях (например, в рабочей базе и в файле поставки или в копии конфигурации), самый надёжный штатный инструмент — механизм сравнения конфигураций. Он покажет различия на уровне объектов метаданных, включая роли.
Порядок действий: откройте конфигуратор, загрузите одну из конфигураций, затем выполните «Конфигурация → Сравнить, объединить с конфигурацией из файла» (или с конфигурацией базы данных, с конфигурацией поставщика). В дереве сравнения найдите ветку «Роли» и посмотрите, помечены ли нужные роли как изменённые.
Ограничение метода: он показывает, что роль изменилась, но детальное сравнение прав по каждому объекту внутри роли в этом окне не всегда наглядно. Для детального анализа различий внутри роли удобнее выгрузить её в файлы и сравнить содержимое (см. следующий раздел).
- 1Сделайте резервную копию базы или выгрузите конфигурацию в файл .cf
- 2Откройте конфигуратор и меню «Конфигурация → Сравнить, объединить с конфигурацией из файла»
- 3Укажите файл второй конфигурации и дождитесь построения дерева различий
- 4Раскройте ветку «Общие → Роли» и найдите нужные роли
- 5Дважды щёлкните по роли, чтобы открыть детальный отчёт о различиях
Способ 2. Выгрузка ролей в XML и сравнение файлов
Наиболее точный способ сравнить две роли «до запятой» — выгрузить конфигурацию в файлы XML и сравнить соответствующие файлы ролей любым инструментом построчного сравнения (Notepad++ с плагином Compare, WinMerge, встроенное сравнение в VS Code и т.п.).
Для выгрузки используйте команду «Конфигурация → Выгрузить конфигурацию в файлы». В каталоге выгрузки каждая роль представлена отдельным XML-файлом в папке Roles. Внутри файла перечислены все объекты и права, а также шаблоны RLS. Если роли находятся в одной конфигурации — выгрузите её один раз и сравните два файла ролей между собой.
Учтите, что XML-представление многословно: одна и та же логическая разница может выглядеть как десятки изменённых строк, а порядок элементов в файле может отличаться без реального различия в правах. Поэтому метод хорош для точного аудита, но требует внимательности при интерпретации.
Способ 3. Сравнение прав через отчёт и сторонние обработки
Если задача — сравнить не сами объекты ролей, а итоговые права, удобно использовать отчётный подход. В типовых конфигурациях с подсистемой управления доступом (на базе БСП) есть отчёт «Права доступа» или аналогичный: он показывает, какие права даёт конкретная роль или профиль группы доступа, в виде таблицы. Сформируйте отчёт для каждой роли и сравните результаты.
Существуют также свободно распространяемые внешние обработки для сравнения ролей: они строят сводную таблицу прав по двум ролям и подсвечивают различия. Такие обработки удобны, когда роли находятся в одной конфигурации и нужно быстро увидеть разницу без выгрузки в файлы.
При использовании сторонних обработок проверяйте их источник и запускайте сначала на копии базы. Обработки скачивают метаданные конфигурации, и ошибка в коде в худшем случае может повлиять на работу сеанса, хотя сама по себе обработка сравнения прав обычно только читает данные.
Сравнение способов
Подходит, когда роли в разных конфигурациях или файлах .cf. Ограничение: слабо детализирует различия внутри одной роли.
Самый точный метод, показывает все различия включая RLS. Ограничение: трудоёмко, много «шума» в файлах.
Быстро и наглядно для итоговых прав. Ограничение: доступен не во всех конфигурациях и не показывает RLS-шаблоны детально.
Удобная таблица различий внутри одной базы. Ограничение: нужно доверять источнику обработки.
Как сравнить фактический доступ пользователей
Часто реальная цель — понять, почему у двух пользователей разный доступ, хотя роли у них вроде бы одинаковые. Здесь сравнения ролей как объектов недостаточно: итоговые права складываются из всех назначенных ролей, профилей групп доступа, а в типовых конфигурациях — ещё и из настроек групп доступа и значений доступа.
Практический приём: создайте тестового пользователя, назначьте ему только первую роль, войдите под ним и зафиксируйте доступные операции. Затем замените роль на вторую и повторите проверку по тому же списку операций. Это трудоёмко, но даёт гарантированно достоверную картину фактического поведения системы.
В типовых конфигурациях на базе БСП дополнительно проверьте: не входит ли пользователь в группы доступа, не назначены ли ему профили напрямую, нет ли индивидуальных настроек. Различия часто кроются именно там, а не в самих ролях.
Как проверить результат
Права на документы и справочники совпадают по отчёту или таблице сравнения
Есть расхождения в правах на объекты, которые должны быть идентичны
Под тестовым пользователем доступны ровно ожидаемые операции
Доступ отличается от ожидаемого — ищите дополнительные роли или группы доступа
Тексты шаблонов ограничения совпадают в обеих ролях
Шаблоны различаются — пользователи увидят разные наборы записей
Типичные ошибки и риски
Самая частая ошибка — сравнивать роли по названию, а не по содержимому. Две роли с одинаковым именем в разных конфигурациях могут иметь существенно разный состав прав, особенно если конфигурации разных версий или одна из них дорабатывалась.
Вторая ошибка — забывать про RLS. Две роли могут давать одинаковые права на объект, но разные ограничения на уровне записей, и пользователь увидит разные данные. Сравнение только по флажкам прав такую разницу не покажет — нужно смотреть шаблоны ограничений.
Третья ошибка — вносить правки в роли рабочей базы без копии. Изменение ролей влияет на всех пользователей сразу после обновления конфигурации базы данных, и ошибочное снятие права может остановить работу целого подразделения.
Как выбрать подходящий метод
Если роли в одной конфигурации и нужна быстрая картина — используйте отчёт по правам или внешнюю обработку сравнения. Если нужен точный аудит с учётом RLS — выгружайте в XML и сравнивайте файлы. Если роли в разных конфигурациях или файлах поставки — начните со штатного сравнения конфигураций.
В любом сценарии завершайте работу проверкой фактического доступа: только тест под реальным пользователем подтверждает, что различия (или их отсутствие) соответствуют ожиданиям.
Как выбрать действие
Что важно запомнить
Прямого инструмента сравнения ролей в 1С нет. Используйте сравнение конфигураций, выгрузку ролей в XML с построчным сравнением или отчёты по правам. Не забывайте про RLS и совокупность назначенных ролей, а результат всегда проверяйте тестовым входом под пользователем. Изменения вносите только после резервного копирования.
Частые вопросы
Можно ли сравнить две роли прямо в конфигураторе одной базы?
Штатной функции сравнения двух ролей внутри одной конфигурации нет. Варианты: выгрузить конфигурацию в файлы и сравнить XML-файлы ролей, либо использовать внешнюю обработку сравнения прав, которая построит таблицу различий.
Почему у пользователей с одинаковыми ролями разный доступ к данным?
Наиболее вероятные причины: разные шаблоны RLS в дополнительно назначенных ролях, членство в разных группах доступа (в типовых конфигурациях), различия в профилях или индивидуальных настройках доступа. Сравнивайте не одну роль, а полный набор назначений каждого пользователя.
Учитывается ли RLS при сравнении через отчёт по правам?
Обычно отчёты показывают права на объекты, но не детализируют текст шаблонов ограничения доступа к данным. Для сравнения RLS надёжнее выгрузить роли в XML и сравнить содержимое файлов — шаблоны хранятся там в явном виде.
Безопасно ли использовать сторонние обработки для сравнения ролей?
Обработки сравнения обычно только читают метаданные, поэтому риск минимален, но запускать их стоит сначала на копии базы и только из доверенного источника. Никогда не запускайте непроверенные обработки в рабочей базе с полными правами.
Что делать, если роли сравниваются в конфигурациях разных версий?
Сначала приведите конфигурации к сопоставимому состоянию или учитывайте, что различия в составе объектов метаданных создадут ложные расхождения в файлах ролей. В этом случае сравнивайте права только по тем объектам, которые существуют в обеих версиях.
Как быстро проверить, что после изменения роли ничего не сломалось?
Создайте тестового пользователя с изменённой ролью, войдите под ним и пройдите по контрольному списку критичных операций: открытие ключевых документов, проведение, формирование отчётов. Дополнительно попросите одного-двух реальных пользователей проверить свою работу до массового применения изменений.