При настройке прав доступа в 1С разработчики часто сталкиваются с ситуацией, когда пользователю необходимо разрешить редактирование лишь одного конкретного поля (реквизита) на форме справочника или документа, оставив все остальные поля закрытыми для изменений. Начинающие специалисты совершают стандартную ошибку: они создают новую роль, дают право на редактирование нужного реквизита и включают право изменения на уровне самого справочника. В результате пользователю открывается доступ ко всем элементам формы без исключения.
В этой статье мы подробно разберем, почему так происходит, рассмотрим внутренние механизмы работы платформы 1С с правами доступа и изучим несколько надежных способов решения этой задачи — от правильной настройки ролей в Конфигураторе до гибкого программного кодирования и использования функциональных опций.
Для начала проанализируем поведение платформы 1С. Когда мы создаем новую роль и хотим ограничить доступ к элементам, мы сталкиваемся с автоматическим наследованием прав. Если в свойствах роли на уровне самого справочника или всей конфигурации установлен флаг «Устанавливать права для реквизитов и табличных частей по умолчанию» (или «Независимые права подчиненных объектов» настроены некорректно), то любое разрешение на изменение родительского объекта (справочника) автоматически каскадно распространяется на все его дочерние объекты — реквизиты, табличные части и их реквизиты.
Кроме того, крайне важно помнить фундаментальное правило работы системы прав в 1С: права пользователя суммируются по принципу логического «ИЛИ». Если у нашего пользователя, помимо новой ограничивающей роли, есть хотя бы одна другая роль (например, базовая роль, роль менеджера продаж или бухгалтера), которая дает полные права на этот справочник, то любые ограничения в новой роли работать не будут. Более разрешающая роль всегда будет иметь приоритет. Для выявления таких пересечений и анализа структуры прав можно использовать обработку для анализа ролей и профилей доступа.
Разберем пошагово, как обойти эти ограничения и решить задачу различными методами.
Если мы хотим решить задачу исключительно средствами администрирования, без написания программного кода, нам необходимо правильно настроить роль. Выполним следующие действия:
Чтение, Просмотр, Изменение и Редактирование на уровне самого справочника. Без права Изменение платформа в принципе заблокирует любую попытку записи элемента справочника в базу данных.Редактирование, но обязательно оставим включенным флаг Просмотр (иначе пользователь просто не увидит эти данные на форме).Просмотр, и Редактирование.Важное предостережение: убедитесь, что у данного пользователя нет других ролей, которые предоставляют право редактирования на закрытые реквизиты этого справочника. Назначьте ему только эту специализированную роль и минимально необходимый набор системных ролей (например, «Пользователь»).
Очень часто разработчики отказываются от настройки ролей в конфигураторе из-за сложности администрирования большого количества ролей и прибегают к программным методам. Автор темы в Сообщении 7 привел пример программного кода, который он назвал «костылем»:
Если СокрЛП(ПараметрыСеанса.ТекущийПользователь.Наименование)="Бородин" Тогда
Для каждого Элемент из ЭлементыФормы Цикл
Элемент.Доступность = Ложь;
КонецЦикла;
ЭтаФорма.ЭлементыФормы.Печатник.Доступность=Истина;
ЭтаФорма.ЭлементыФормы.Закрыть.Доступность=Истина;
ЭтаФорма.ЭлементыФормы.Записать.Доступность=Истина;
ЭтаФорма.ЭлементыФормы.ОК.Доступность=Истина;
ЭтаФорма.ЭлементыФормы.ПозвонитьRingoline.Доступность=Истина;
КонецЕсли;
Этот код действительно является «костылем» и содержит критические архитектурные ошибки:
Наименование = "Бородин" крайне ненадежна. Если сотрудник сменит фамилию, уволится, или в системе появится его однофамилец, код перестанет работать корректно или потребует немедленного вмешательства программиста для изменения конфигурации.ЭлементыФормы в цикле и отключение доступности у всех подряд элементов может сломать интерфейс (например, заблокировать системные кнопки, декорации, группы или панели, которые вообще не связаны с реквизитами данных).Давайте перепишем этот алгоритм правильно и профессионально. Мы будем использовать проверку наличия роли у текущего пользователя, а не его имени. Также мы задействуем свойство формы ТолькоПросмотр вместо блокировки каждого отдельного элемента.
Рассмотрим правильный пример программного кода для обычных форм (где используется коллекция ЭлементыФормы):
Процедура ПриОткрытии()
// Проверяем, есть ли у пользователя роль, позволяющая редактировать весь справочник
Если Не РольДоступна("ПолныеПрава") И Не РольДоступна("РедактированиеСправочникаКонтрагенты") Тогда
// Переводим всю форму в режим "Только просмотр"
ЭтаФорма.ТолькоПросмотр = Истина;
// Делаем исключение для конкретного элемента формы
// Пользователь сможет редактировать только это поле, несмотря на ТолькоПросмотр формы
ЭлементыФормы.Печатник.Доступность = Истина;
// Системные кнопки управления формой также должны оставаться доступными
ЭлементыФормы.ОсновныеДействияФормы.Кнопки.Записать.Доступность = Истина;
ЭлементыФормы.ОсновныеДействияФормы.Кнопки.ОК.Доступность = Истина;
КонецЕсли;
КонецПроцедуры
Если ваша конфигурация использует современные управляемые формы, то программный код в модуле формы (в обработчике события ПриСозданииНаСервере) будет выглядеть еще лаконичнее и надежнее. Обратите внимание, что вместо свойства Доступность для элементов интерфейса лучше использовать свойство ТолькоПросмотр, так как оно позволяет пользователям выделять и копировать текст из заблокированных полей:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем роль текущего пользователя
Если Не РольДоступна("РазрешитьРедактированиеВсегоСправочника") Тогда
// Блокируем для редактирования всю форму целиком
ЭтотОбъект.ТолькоПросмотр = Истина;
// Разрешаем редактирование конкретного элемента формы
Элементы.Печатник.ТолькоПросмотр = Ложь;
КонецЕсли;
КонецПроцедуры
Для управляемого интерфейса платформа предлагает удобный инструмент интерактивной настройки видимости и доступности полей в зависимости от ролей прямо в редакторе формы. Этот метод не требует написания кода.
Разберем этот процесс по шагам:
Преимущества: Простота настройки и наглядность в конфигураторе.
Недостатки: Согласно стандартам разработки фирмы «1С», этот метод не рекомендуется активно использовать в крупных конфигурациях с большим количеством ролей (более 50-100), так как это сильно усложняет последующую поддержку, обновление и аудит безопасности системы. Кроме того, продвинутый пользователь может попытаться обойти это ограничение через меню «Изменить форму», если разработчик предварительно не отключил свойство формы РазрешитьИзменениеФормы.
В Сообщении 9 участники обсуждения рекомендуют использовать механизм функциональных опций. Это очень мощный системный инструмент, позволяющий динамически управлять интерфейсом программы.
Обычно функциональные опции привязываются к константам или значениям реквизитов (например, «Использовать учет по нескольким организациям»). Но мы можем привязать функциональную опцию к параметру сеанса, значение которого будет определяться при старте системы в зависимости от ролей пользователя:
ДоступноРедактированиеПечатника с типом Булево.УстановкаПараметровСеанса пропишем инициализацию этого параметра:
ПараметрыСеанса.ДоступноРедактированиеПечатника = РольДоступна("РольПечатника");
ДоступноРедактированиеПечатника.Истина.Этот способ идеален, если ограничение должно работать глобально по всей системе для многих объектов конфигурации. Для одного-единственного реквизита на одной форме этот метод может показаться избыточным, но архитектурно он является одним из самых чистых.
Если вы ведете разработку в типовой конфигурации (такой как 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей или 1С:Бухгалтерия), то в вашем распоряжении уже есть готовые механизмы Библиотеки стандартных подсистем (БСП).
В БСП встроена замечательная подсистема «Запрет редактирования реквизитов объектов». Она позволяет заблокировать ключевые реквизиты объектов после их записи в базу данных. При этом на форме появляется кнопка «Разрешить редактирование реквизитов» (в меню «Еще»). Обычные пользователи видят форму закрытой для редактирования, а нажать кнопку активации полей могут только пользователи со специальной ролью (обычно это администраторы или редакторы нормативно-справочной информации). Для автоматизации этой процедуры у определенных пользователей можно применить расширение для автоматического разрешения редактирования ключевых реквизитов.
Интеграция вашего справочника с этой подсистемой выполняется через добавление справочника в определенные определяемые типы БСП и написание нескольких строк кода в модуле формы для вызова методов БСП. Это стандартный и наиболее предпочтительный путь разработки в среде современных типовых решений фирмы «1С».
Мы проанализировали проблему и рассмотрели несколько путей ее решения. Выбор конкретного метода зависит от архитектуры вашей базы данных:
ТолькоПросмотр = Истина для формы и ТолькоПросмотр = Ложь для нужного элемента, обязательно проверяя роль пользователя через функцию РольДоступна().