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