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