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