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