В рамках работы с конфигурациями 1С, особенно при активном использовании расширений и Библиотеки стандартных подсистем (БСП), разработчики и администраторы часто сталкиваются с проблемой "слетающих" прав пользователей. Пользовательские права, установленные через роли в расширениях, могут самопроизвольно сбрасываться в конфигураторе или после различных обновлений. Мы рассмотрим эту проблему подробно, выясним её основные причины и предложим проверенные подходы к решению, основываясь на опыте сообщества 1С.
Давайте проанализируем сценарии, в которых проявляется данная проблема, основываясь на опыте сообщества 1С. Мы столкнулись с ситуацией, когда пользовательская роль, добавленная в расширение, а затем в профиль и группу доступа, сохраняется в режиме "1С:Предприятие", но сбрасывается в конфигураторе при обновлении. Более того, выясняется, что роль может слетать и без явного обновления конфигурации.
Выделим ключевые факторы, которые приводят к описанной проблеме. Мы рассмотрим, как взаимодействуют расширения, БСП и механизмы управления доступом 1С, чтобы понять корень проблемы.
Одна из наиболее распространённых и критических причин связана с особенностями работы Библиотеки стандартных подсистем. Если пользователь имеет полные права или включен в предопределенный профиль групп доступа «Администратор», регламентные задания БСП, использующие процедуру ОбновитьРолиПользователей (в модуле УправлениеДоступомСлужебный), могут активно очищать все "лишние" роли пользователя.
БСП стремится привести состав ролей администратора к минимально необходимому, полагая, что полных прав достаточно, чтобы охватить все возможности. В этом процессе роли, добавленные через расширения, часто игнорируются или считаются избыточными для пользователя с полными правами.
В результате, даже если вы вручную назначили роль из расширения пользователю с полными правами, БСП считает её избыточной и удаляет при следующем выполнении регламентного задания. Именно этот сценарий был подтвержден в нашем обсуждении.
При каждом обновлении основной конфигурации 1С происходит анализ всех ролей и прав. Если структура ролей расширения меняется, или если расширение обновляется с помощью операций сравнения/объединения (что эквивалентно пересозданию), платформа может сбросить назначенные ранее права, чтобы обеспечить консистентность с новой структурой метаданных. Это стандартное поведение платформы, направленное на предотвращение некорректных состояний после структурных изменений.
Режим совместимости конфигурации также играет роль в поведении системы, в том числе и с ролями. В старых режимах совместимости (например, 8.3.13 и ранее) действовало правило: если в расширении нет собственных ролей, доступ ко всем его объектам предоставляется всем пользователям. Однако как только в расширении появляются роли, необходимо явно назначать права на объекты расширения. Некорректное управление ролями в расширении с учетом установленного режима совместимости может привести к неожиданным сбросам прав или их некорректному применению.
В свойствах расширения существует опция "Использовать основные роли для всех пользователей". Если это свойство включено, основные роли, указанные в расширении, применяются для всех пользователей конфигурации, и в режиме "1С:Предприятие" доступна ручная установка прав для каждого пользователя. Если же свойство установлено в "Ложь", то администратор должен будет добавить роли расширения пользователям в явном виде. Неправильная настройка этого свойства может влиять на видимость и применимость ролей расширения, приводя к их "слетанию" для отдельных категорий пользователей.
Как было упомянуто в обсуждении, некоторые конфигурации, например, "ЖКХ", могут содержать специфический код, который не полностью согласуется с принципами работы БСП или расширений. Если в такой конфигурации используются устаревшие или кастомные механизмы управления правами, это может приводить к конфликтам и самопроизвольному сбросу ролей, особенно если эти механизмы конкурируют с логикой БСП.
Для минимизации или полного устранения проблемы "слетающих" прав мы предлагаем следующие рекомендации и подходы, сочетающие стандартные механизмы 1С и БСП с проверенными практиками разработки.
Мы настоятельно рекомендуем всегда использовать стандартные механизмы управления доступом БСП вместо прямого назначения ролей пользователям в конфигураторе. Этот подход обеспечивает централизованное и более стабильное управление правами.
При использовании этого подхода БСП сможет корректно обрабатывать права при обновлениях, так как она оперирует профилями и группами доступа. При необходимости, после обновления, достаточно будет **перезаписать группу доступа**, чтобы обновить состав прав пользователей и гарантировать актуальность назначений.
ОбновитьРолиПользователей (только в крайних случаях и с осторожностью):
В ситуации, когда пользователи с полными правами теряют доступ к функционалу расширения из-за "чистки" БСП, как это было подтверждено в сообщении 11, может потребоваться точечная модификация процедуры ОбновитьРолиПользователей в модуле УправлениеДоступомСлужебный.
Мы можем добавить код в режиме "Изменение и контроль", который будет сохранять роли из расширений для администраторов, а затем восстанавливать их после выполнения типовой логики БСП. Это сложный метод, требующий глубокого понимания БСП, и его следует применять с максимальной осторожностью, поскольку изменения в типовом коде всегда несут риски.
Основная идея заключается в том, чтобы перед тем, как БСП очистит роли для администраторов, мы сохранили те роли, что относятся к нашим расширениям. После выполнения типовой очистки, мы должны добавить эти сохраненные роли обратно пользователю. Ниже представлен пример логики, который потребует адаптации под конкретную версию БСП и структуру вашего расширения:
// В процедуре ОбновитьРолиПользователей (Изменение и контроль)
// До очистки ролей для администраторов:
// Получаем роли из расширения, которые должны быть сохранены
МассивСохраняемыхРолейРасширения = Новый Массив;
Для Каждого РольТекущегоПользователя Из Пользователь.Роли Цикл
// Используем префикс расширения для идентификации ролей
// Пример: Если ваше расширение называется "МоеРасширение",
// то роли будут иметь имена вида "МоеРасширение_МояРоль" или
// метаданные ролей расширения будут иметь другое имя конфигурации
Если СтрНачинаетсяС(РольТекущегоПользователя.Имя, "ПрефиксМоегоРасширения_") ИЛИ
(РольТекущегоПользователя.Метаданные().ИмяКонфигурации = "ИмяВашегоРасширенияВКонфигураторе") Тогда
МассивСохраняемыхРолейРасширения.Добавить(РольТекущегоПользователя.Имя);
КонецЕсли;
КонецЦикла;
// ... далее следует типовой код БСП по очистке ролей для администраторов.
// Этот код может выглядеть примерно так:
// Если ПользовательЯвляетсяАдминистратором Тогда
// ОчиститьЛишниеРоли(Пользователь);
// КонецЕсли;
// Мы предполагаем, что типовой код БСП выполнится между сохранением и восстановлением.
// После очистки ролей для администраторов:
// Восстанавливаем сохраненные роли
Для Каждого ИмяРоли Из МассивСохраняемыхРолейРасширения Цикл
// Получаем объект метаданных роли
МетаданныеРоли = Метаданные.НайтиПоПолномуИмени("Роль." + ИмяРоли);
Если МетаданныеРоли <> Неопределено Тогда
Если Не Пользователь.Роли.Содержит(МетаданныеРоли) Тогда
Пользователь.Роли.Добавить(МетаданныеРоли);
КонецЕсли;
КонецЕсли;
КонецЦикла;
Помните, что любое изменение типового функционала БСП требует тщательного тестирования и может потребовать повторной адаптации после обновлений самой БСП. Рекомендуется документировать все такие изменения.
Если вы хотите предоставить администраторам доступ ко всему функционалу вашего расширения (что логично для администратора), необходимо заимствовать типовую роль "ПолныеПрава" в ваше расширение. Это не означает, что вы изменяете типовую роль, а создаете её "проекцию" внутри расширения.
В заимствованной роли "ПолныеПрава" в расширении установите все необходимые права на объекты, которые вы добавили или изменили в расширении. Таким образом, администраторы, имеющие эту роль, получат полный доступ к функционалу расширения, и их права будут управляться через эту заимствованную роль.
Важно: Для роли "ПолныеПрава" в расширении (и только для неё) рекомендуется установить флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят, чтобы избежать неконтролируемого расширения прав.
Мы рекомендуем создавать роли, которые предоставляют права на элементарные, неделимые функции программы. Из этих "атомарных" ролей затем формируйте профили пользователей. Например, вместо одной большой роли "МенеджерПоПродажам" создайте роли "ПросмотрЗаказов", "ИзменениеЗаказов", "СозданиеСчетов".
Такой подход упрощает управление правами, делает их более стабильными и гибкими. Если вам потребуется изменить какой-либо аспект прав, вы сможете сделать это, изменив одну небольшую роль, а не пересобирая большой набор.
Старайтесь не изменять типовые роли основной конфигурации через расширение, чтобы не нарушать целостность и логику БСП. Вместо этого, создавайте собственные роли для специфического функционала вашего расширения. Если необходимо предоставить доступ к модифицированным объектам или новым реквизитам, создайте отдельную роль в расширении и включите её в соответствующие профили групп доступа БСП.
/С ЗапуститьОбновлениеИнформационнойБазы при обновлениях:
В случае, если права слетают после обновления, и вы не используете БСП для управления доступом или хотите гарантировать применение всех изменений после обновления конфигурации, рассмотрите возможность запуска базы с ключом командной строки /С ЗапуститьОбновлениеИнформационнойБазы. Этот ключ может помочь корректно применить изменения после обновления конфигурации, включая структуры ролей.
После такого запуска, возможно, потребуется вручную перезаписать группы доступа или профили, чтобы убедиться, что все права актуализированы. Однако, следует понимать, что это не панацея от конфликтов с БСП для пользователей с полными правами, так как регламентные задания БСП могут продолжить свою работу.
При программной проверке доступности роли в конфигурациях на базе БСП рекомендуется использовать функцию РолиДоступны общего модуля Пользователи, а не просто РольДоступна. Функция Пользователи.РолиДоступны учитывает все механизмы БСП, включая профили, группы доступа и особенности работы с расширениями, предоставляя более надежный результат.
Пример:
Если Пользователи.РолиДоступны("МояНоваяРольИзРасширения") Тогда
// Выполняем действия, доступные по этой роли
Сообщить("У пользователя есть доступ к функционалу по роли 'МояНоваяРольИзРасширения'");
Иначе
Сообщить("У пользователя нет доступа к функционалу по роли 'МояНоваяРольИзРасширения'");
КонецЕсли;
Если вы добавляете новый реквизит в заимствованный справочник или документ через расширение, не забудьте захватить в расширение роль, которая предоставляет права на этот справочник/документ, и установить соответствующие права на новый реквизит. Иначе реквизит может быть невидим на форме из-за отсутствия прав, даже если у пользователя есть общие права на родительский объект.
Всегда проводите комплексное тестирование после каждого обновления основной конфигурации или изменения расширения. Убедитесь, что все пользователи имеют необходимые права и функциональность расширения доступна корректно. Создайте тестовые сценарии для различных категорий пользователей (администраторы, рядовые пользователи с разными профилями) и проверьте их работоспособность.
Таким образом, проблема "слетающих" прав в 1С при использовании расширений и БСП является многогранной. Понимание механизмов взаимодействия БСП с ролями, особенно для администраторов, и следование рекомендуемым практикам управления доступом позволяет значительно повысить стабильность работы системы и избежать непредвиденных потерь прав, обеспечивая надежное функционирование вашей информационной базы.