← На главную
При обновлении нетиповых конфигураций 1С одной из самых трудоемких задач является разрешение конфликтов в ролях, когда режим сравнения показывает статус «дважды измененные». В крупных конфигурациях список прав роли содержит десятки тысяч строк, из-за чего ручной построчный анализ становится неэффективным. Разберем по шагам, почему возникают массовые расхождения, как быстро выявить реальные изменения и какое решение принимать при объединении.
Выясним причины массовых расхождений в ролях
Прежде чем приступать к объединению, проанализируем ситуацию и определим, почему одна роль может выдавать тысячи строк различий при сравнении конфигураций:
- Флаг «Устанавливать права для новых объектов»: если в роли взведен данный признак, платформа 1С автоматически назначает этой роли полные права на абсолютно все вновь создаваемые объекты конфигурации. При добавлении разработчиком новых справочников или документов в типовую роль автоматически прописываются права, что порождает ложные различия со следующим типовым релизом.
- Добавление новых реквизитов и табличных частей: при включенном наследовании прав появление новых типовых реквизитов в обновлении поставщика фиксируется как изменение состава прав существующего объекта.
- Изменения в шаблонах и условиях RLS (ограничение доступа на уровне записей): расхождение может заключаться не в галочках базовых прав (чтение, добавление, изменение), а в текстах запросов RLS, что не всегда очевидно при обычном просмотре дерева метаданных.
Методика трехстороннего анализа различий
Если роль находится в статусе дважды измененной, просто взять версию из новой конфигурации поставщика нельзя, так как пропадут доработки рабочей базы. Оставить старую версию тоже нельзя — пользователи потеряют доступ к новым объектам и реквизитам обновления. Разберем поэтапный алгоритм выявления реальных изменений.
- Сравнение старого поставщика с новым поставщиком: открываем сравнение конфигураций между предыдущей типовой версией поставщика и новым релизом. Здесь мы четко увидим только те изменения, которые внес вендор: новые объекты метаданных, обновленные условия RLS и скорректированные типовые права.
- Сравнение старого поставщика с рабочей конфигурацией: анализируем, какие именно нетиповые права были добавлены в рабочую базу ранее. Это могут быть права на добавленные нетиповые подсистемы, документы, отчеты или специфические ограничения для пользователей.
- Сопоставление пересечений: объекты, затронутые одновременно в обоих сравнениях, требуют ручной корректировки условий. Для остальных объектов применяется простое объединение.
Технические способы быстрого поиска отличий
Рассмотрим практические инструменты, позволяющие избежать ручного просмотра десятков тысяч строк в окне свойств роли.
- Штатное окно детального сопоставления прав: в окне сравнения и объединения конфигураций дважды кликаем по нужной роли. В открывшемся окне сопоставления прав настраиваем фильтры, установив режим отображения только отличающихся прав и исключив совпадающие элементы.
- Выгрузка конфигурации в XML-файлы: выполняем команду платформы
Выгрузить конфигурацию в файлы для трех состояний конфигурации (старый поставщик, рабочая база, новый поставщик). Каждая роль сохраняется в виде отдельного XML-файла. С помощью внешних программ трехстороннего слияния (diff/merge утилит) сопоставляем файлы роли, что позволяет за секунды локализовать измененные блоки прав и тексты RLS без выгрузки в электронные таблицы. - Проверка прав через панель «Дополнительно»: в дереве метаданных открываем контекстное меню, выбираем пункт
Дополнительно и переходим на вкладку Права. Спозиционировавшись на анализируемой роли, закрепляем панель и последовательно просматриваем только добавленные нетиповые объекты метаданных. Это позволяет быстро проверить наличие прав роли на собственные объекты системы.
Правила объединения и архитектурные рекомендации по стандартам БСП
Для минимизации трудозатрат при текущем и всех последующих обновлениях придерживаемся следующих правил:
- Приоритет обновления поставщика: для типовых ролей выбираем режим объединения с приоритетом новой конфигурации поставщика, после чего точечно возвращаем права на добавленные нетиповые объекты.
- Отказ от модификации типовых ролей: лучшей практикой по стандартам разработки 1С:БСП является сохранение типовых ролей на полной поддержке без изменений. Для всех добавленных нетиповых объектов создаем собственные отдельные роли (например,
ЧтениеНетиповыхДокументов, ДобавлениеНетиповыхСправочников). - Использование профилей групп доступа: созданные нетиповые роли включаются в типовые или новые
ПрофилиГруппДоступа в режиме «1С:Предприятие». Это полностью исключает конфликт дважды измененных ролей при обновлении конфигурации. - Вынос доработок в расширения: при наличии возможности права на новые и заимствованные объекты выносятся в расширения конфигурации, сохраняя основную конфигурацию максимально близкой к типовой.
Обязательные действия после объединения ролей
Посмотрим, какие операции необходимо выполнить после завершения процесса объединения метаданных:
- Проверка синтаксиса RLS: если в роли используются ограничения на уровне записей, платформа не объединяет пересекающиеся тексты условий автоматически. Обязательно проверяем корректность синтаксиса запросов в шаблонах ограничений.
- Обновление параметров доступа в пользовательском режиме: после первого запуска обновленной информационной базы на базе БСП необходимо дождаться завершения фоновых или интерактивных процедур обновления прав доступа. В противном случае измененные права и ограничения RLS не применятся к пользователям из-за неактуального кеша в регистрах прав.