В процессе разработки и настройки конфигураций на базе платформы «1С:Предприятие 8» (особенно в типовых решениях, таких как ЗУП 3.1) часто возникает необходимость в тонком разграничении прав доступа. Стандартная задача обычно заключается в том, чтобы скрыть данные от рядовых сотрудников. Но как поступить, если требуется обратное: скрыть конфиденциальную информацию (например, специфические дополнительные реквизиты) от пользователей с ролью «Полные права», оставив их доступными только узкому кругу лиц?
Давайте подробно разберем, почему стандартные механизмы проверки прав в Библиотеке Стандартных Подсистем (БСП) не всегда работают так, как ожидается, для чего может потребоваться быстрая проверка прав доступа на объект метаданных, и рассмотрим эффективные программные способы решения этой задачи.
Рассмотрим типичный сценарий: в справочнике «Сотрудники» созданы дополнительные реквизиты. Мы разработали специальную роль РедактированиеДопРеквКадры и хотим, чтобы данные реквизиты были видны исключительно обладателям этой роли. Для всех остальных пользователей, включая администраторов с полными правами, они должны быть скрыты.
Если использовать стандартную функцию БСП, код проверки может выглядеть следующим образом:
// Попытка проверки права через БСП
Если УправлениеДоступом.ЕстьРоль("РедактированиеДопРеквКадры") Тогда
Элементы.НашСпецРеквизит.Видимость = Истина;
Иначе
Элементы.НашСпецРеквизит.Видимость = Ложь;
КонецЕсли;
Однако при тестировании выяснится, что «Администратор» все равно видит этот реквизит, даже если роль РедактированиеДопРеквКадры не была ему назначена. Причина заключается в логике работы УправлениеДоступом.ЕстьРоль(): эта функция проверяет наличие эффективного права. Изучая нюансы проверки прав в современных конфигурациях и проводя анализ прав и ролей для поиска подходящего профиля (удобно через обработка для детального анализа прав доступа и RLS), важно помнить, что в системе 1С роль «Полные права» по умолчанию включает доступ ко всем объектам и функциям, поэтому для администратора проверка всегда будет возвращать Истина.
Чтобы исключить влияние «Полных прав» при проверке, необходимо обратиться к методам платформы, которые работают иначе, чем обертки БСП. Метод РольДоступна() проверяет наличие конкретной роли в текущем сеансе. Однако, так как полные права часто поглощают другие права, наиболее надежным способом будет явное исключение администраторов из условия. Кроме того, можно использовать готовый инструмент контроля видимости и доступности элементов управляемой формы для более гибкого управления интерфейсом без сложного кодинга.
Пример кода, реализующий логику скрытия реквизита от администратора:
// Проверяем наличие спец. роли с учетом исключения Полных прав
ДоступКРеквизиту = Ложь;
// 1. Проверяем наличие нашей специализированной роли
Если РольДоступна("РедактированиеДопРеквКадры") Тогда
ДоступКРеквизиту = Истина;
КонецЕсли;
// 2. Явное ограничение для администраторов
Если РольДоступна("ПолныеПрава") Тогда
// Если мы хотим жестко запретить доступ даже администраторам
ДоступКРеквизиту = Ложь;
// Либо используем проверку явного назначения (см. Решение 2)
КонецЕсли;
Элементы.СекретныйРеквизит.Видимость = ДоступКРеквизиту;
Подобная тонкая настройка прав доступа и использование конструкции Если РольДоступна("ПолныеПрава") позволяет идентифицировать администратора и программно управлять видимостью элементов формы.
Если задача звучит так: «Скрыть от администратора, если роль не выдана ему персонально, но показать, если выдана», метод РольДоступна() может быть недостаточно точным. В этой ситуации стоит провести анализ коллекции ролей текущего пользователя, чтобы определить реально установленные права.
Этот способ позволяет определить, была ли роль назначена пользователю «галочкой» в конфигураторе или в режиме «1С:Предприятие», игнорируя эффект поглощения прав.
Функция РольНазначенаЯвно(ИмяИскомойРоли)
ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
Для Каждого РольПользователя Из ТекущийПользователь.Роли Цикл
// Сравниваем имена ролей метаданных
Если РольПользователя.Имя = ИмяИскомойРоли Тогда
Возврат Истина;
КонецЕсли;
КонецЦикла;
Возврат Ложь;
КонецФункции
Использование функции в модуле формы:
// Показываем реквизит только тем, кому роль выдана персонально
Элементы.ДопРеквизит.Видимость = РольНазначенаЯвно("РедактированиеДопРеквКадры");
Даже если у пользователя есть полные права, но роль РедактированиеДопРеквКадры не добавлена ему в профиль явно, реквизит будет скрыт.
Для современных конфигураций на платформе 8.3.10+ стоит рассмотреть использование расширений для реализации изолированных прав доступа. Например, специальное расширение для настройки доступности элементов формы позволит управлять видимостью, доступностью и режимом «только просмотр» без внесения изменений в основную конфигурацию.
Основные этапы при ручной настройке:
Расш1_ДоступКДанным).Важный нюанс: роль «Полные права» из основной конфигурации не получает прав на объекты расширения автоматически (если это не настроено специально). Таким образом, администратор не увидит данные до тех пор, пока вы не назначите ему роль из расширения явно.
Необходимо четко разграничивать «скрытие видимости на форме» и «запрет доступа к данным». Описанные программные методы управления видимостью элементов формы — это защита интерфейса от перегрузки или «любопытных глаз», но не полноценная защита данных от пользователя с административными правами.
Почему это важно помнить:
ВЫБРАТЬ...) значения скрытых реквизитов будут видны, так как RLS (ограничение доступа на уровне записей) для полных прав обычно игнорируется.Если требуется гарантированное сокрытие критически важных данных (например, размеров премий топ-менеджмента или специфических настроек системы), необходимо использовать шифрование данных или физическое разделение административных профилей. Хорошим примером реализации разделения прав является решение, обеспечивающее доступ к дате запрета редактирования независимо от полных прав в 1С:ЗУП, где критический параметр защищен даже от администратора.
Для эффективного управления видимостью реквизитов от пользователей с полными правами:
УправлениеДоступом.ЕстьРоль(), так как она всегда возвращает Истина для администратора.РольДоступна("ПолныеПрава") для принудительного отключения видимости в коде формы.ПользователиИнформационнойБазы для анализа персональных прав.