При настройке ролей в системе «1С:Предприятие 8» разработчики часто сталкиваются с парой прав, которые на первый взгляд кажутся дублирующими друг друга: «Изменение» (Update) и «Редактирование» (Edit). Однако за этим лингвистическим сходством скрывается принципиальное разделение уровней доступа. В этой статье мы подробно разберем, как работают эти механизмы, почему одно невозможно без другого и как правильно настраивать права для обеспечения безопасности данных.
Для начала проанализируем ситуацию на уровне архитектуры платформы. В 1С права жестко разделены на два основных слоя: уровень доступа к данным (ядро) и уровень взаимодействия с пользователем (интерфейс).
Право «Изменение» (Update) относится исключительно к уровню базы данных. Это базовое право, которое определяет, имеет ли субъект (пользователь или программный процесс) техническую возможность модифицировать запись в таблице БД. Если это право предоставлено, система позволит выполнить запись объекта программным путем. Рассмотрим это на примере кода:
ОбъектСправочника = Справочники.Номенклатура.НайтиПоКоду("00001").ПолучитьОбъект();
ОбъектСправочника.Наименование = "Новое наименование";
// Если у пользователя есть право "Изменение", метод выполнится успешно
ОбъектСправочника.Записать();
Право «Редактирование» (Edit) — это чисто интерфейсное ограничение. Оно не влияет на работу программных методов, но управляет доступностью элементов управления в формах. Если у пользователя есть право на «Изменение», но нет права на «Редактирование», он сможет увидеть данные, но все поля в стандартных формах (в списках или формах объектов) станут доступны только для чтения. Кнопки «Записать», «ОК» или «Провести» будут либо скрыты, либо заблокированы платформой автоматически.
Разберем по шагам, как права зависят друг от друга. В системе 1С выстроена логическая цепочка, где более «высокие» (интерактивные) права требуют наличия «низких» (базовых). Проанализируем эту зависимость:
Выясним причину, почему конфигуратор ведет себя определенным образом: если вы попробуете в окне настройки роли снять галочку с права Изменение, платформа автоматически снимет галочку и с Редактирования. Это логично, так как нет смысла разрешать пользователю нажимать кнопки в интерфейсе, если сама база данных отвергнет попытку записи.
Рассмотрим подробнее работу с регистрами сведений, накопления, расчета и бухгалтерии. Здесь нас ждет важная деталь: для большинства регистров права Редактирование не существует в принципе. В дереве метаданных для этих объектов доступно только право Изменение.
Это связано с тем, что записи регистров обычно не имеют таких сложных независимых форм, как справочники или документы. Изменение данных в регистрах чаще всего происходит двумя путями:
Проанализируем, как отсутствие права Редактирование влияет на пользовательский опыт. Если мы лишим пользователя этого права, произойдут следующие изменения в интерфейсе:
При этом, если право Просмотр сохранено, пользователь все еще сможет изучать данные, строить по ним отчеты и анализировать информацию, что крайне полезно для аудиторов или руководителей.
Рассмотрим ситуацию, когда мы создаем свою собственную форму «с нуля», не полагаясь на стандартные механизмы платформы. Важно помнить, что автоматическая блокировка элементов управления работает безупречно только в стандартных формах.
Если разработчик создает сложный интерфейс программно, ему может потребоваться самостоятельно проверить право доступа, чтобы вовремя заблокировать нужные кнопки. Для этого мы используем функцию ПравоДоступа(). Посмотрим на пример кода:
Если НЕ ПравоДоступа("Редактирование", Метаданные.Справочники.Контрагенты) Тогда
Элементы.ГруппаКомандыЗаписи.Доступность = Ложь;
ТолькоПросмотр = Истина;
КонецЕсли;
В то же время право Изменение проверяется платформой всегда на уровне ядра в момент вызова метода Записать(). Даже если вы забудете заблокировать кнопку на своей форме, попытка записи вызовет исключение «Нарушение прав доступа», если базовое право Изменение отсутствует.
Выясним, как ведут себя права при интеграции систем. При работе через COM-соединение, Web-сервисы или REST API право Редактирование полностью игнорируется. Это происходит потому, что в этих режимах отсутствует интерактивный пользовательский интерфейс.
Для успешной синхронизации данных или загрузки информации из внешних источников пользователю (под которым устанавливается соединение) достаточно иметь только право Изменение. Это позволяет создавать «технических пользователей» с минимально необходимым набором прав, не давая им лишних полномочий в интерфейсе самой программы.
Напоследок разберем связь с механизмом RLS (Row Level Security). Условия ограничения доступа на уровне записей настраиваются именно для права «Изменение». Нельзя настроить разные правила RLS отдельно для Редактирования и Изменения.
Если настроенный шаблон RLS запрещает пользователю менять конкретный экземпляр документа (например, закрытый период), то даже при наличии всех галочек «Редактирование» в роли, попытка сохранения документа закончится ошибкой. Система сначала проверит общие права (роли), а затем применит детальный фильтр RLS к праву Изменение.
Таким образом, понимание разницы между этими двумя правами позволяет гибко настраивать систему: давать роботам право только на Изменение, а пользователям — полный комплект прав для комфортной работы в формах.