← На главную

При разграничении прав доступа в типовых конфигурациях (например, «1С:Управление торговлей 11», «1С:ERP», «1С:Комплексная автоматизация») нередко возникает ситуация: пользователю назначена специализированная роль на добавление и изменение документов движения товаров, непроведенные документы прекрасно редактируются, однако стоит документу перейти в проведенное состояние, как его форма полностью блокируется. При этом командные панели табличных частей становятся неактивными, поля блокируются для ввода, а поиск кода в процедурах модуля формы (ПриОткрытии, ПриСозданииНаСервере, ПриЧтенииНаСервере) или подписках на события не дает никаких результатов.

Разберем по шагам природу такого поведения платформы 1С:Предприятие, выясним причину блокировки и рассмотрим способы корректной настройки прав доступа.

Механизм платформенного перевода формы в режим «Только просмотр»

Проанализируем, почему код в модулях формы может отсутствовать, но форма все равно оказывается недоступной для ввода. В платформе 1С:Предприятие за работу документов отвечают не только базовые CRUD-права (чтение, добавление, изменение, удаление), но и специализированные интерактивные права.

Когда пользователь открывает форму проведенного документа, платформа на уровне системного ядра автоматически проверяет наличие права Интерактивное изменение проведенных. Если этого права у пользователя нет (ни в одной из назначенных ролей), платформа принудительно устанавливает свойству формы ТолькоПросмотр значение Истина. Это происходит еще до выполнения или в процессе инициализации стандартных событий расширения формы документа. В результате отключается возможность модификации реквизитов, а в табличных частях блокируются кнопки добавления, удаления и перемещения строк.

Именно поэтому поиск по коду конфигурации не приводит к успеху: программного кода, запрещающего редактирование, просто нет — ограничение накладывается самим механизмом прав платформы.

Пошаговое решение: проверка и включение права в роли

Если требуется предоставить пользователям возможность редактировать уже проведенные документы соответствующего вида, выполним следующие действия:

1. Откроем конфигуратор и перейдем к списку метаданных.
2. Найдем роль, которая назначена пользователю (или отвечает за работу с данным документом, например, ДобавлениеИзменениеДокументовДвиженияТоваров либо специализированную роль ДобавлениеИзменениеПеремещенийТоваров).
3. В дереве прав роли раскроем ветку Документы и найдем интересующий объект (например, ПеремещениеТоваров).
4. В списке прав найдем флаг Интерактивное изменение проведенных. Убедимся, что он включен.
5. Проверим наличие сопутствующих прав: для того чтобы пользователь мог сохранить скорректированный документ, ему также потребуются права Интерактивное проведение и, при необходимости изменения движений, Интерактивная отмена проведения.
6. Обновим конфигурацию базы данных.

Различие между правами «Изменение» и «Редактирование»

Рассмотрим подробнее важный нюанс платформы, о котором часто забывают при тонкой настройке прав. В системе разделены понятия модификации данных на уровне сервера и на уровне интерфейса:

1. Изменение (Edit): настраивается на уровне самого объекта метаданных. Позволяет модифицировать объект программно через код (например, при вызове методов объекта в привилегированном режиме или обработках).
2. Редактирование (Edit): настраивается на уровне отдельных реквизитов, табличных частей и их колонок. Оно определяет, имеет ли право пользователь интерактивно вводить и менять значения в полях формы. Если право «Изменение» на документ есть, но на конкретный реквизит снято право «Редактирование», поле останется недоступным для ввода даже при разрешенном изменении документа.

Дополнительные факторы, блокирующие редактирование в типовых решениях

Если право Интерактивное изменение проведенных установлено, но форма все равно заблокирована, проанализируем другие прикладные механизмы типовых конфигураций на базе БСП:

1. Подсистема «Запрет редактирования реквизитов объектов»: для предотвращения расхождения движений в закрытых статусах (например, статус «Принято» в перемещении) программа блокирует ключевые поля. В командной панели формы появляется кнопка Еще – Разрешить редактирование реквизитов. Для ее использования у пользователя должна быть роль РедактированиеРеквизитовОбъектов.
2. Ограничение на уровне записей (RLS) по складам: в перемещении участвуют два склада — склад-отправитель и склад-получатель. Если в системе включен RLS по складам, для проведения документа в статусе фактической приемки («Принято») пользователю необходимы полные права на запись по обоим складам. Если к складу-получателю доступ настроен только на чтение, провести или изменить такой документ пользователь не сможет.
3. Даты запрета изменения данных: если дата документа попадает в закрытый период (общий, по организации или по разделу учета), форма автоматически переходит в режим только для чтения независимо от состава ролей.
4. Ордерная схема документооборота: если перемещение является распоряжением для оформления ордеров, а фактические ордера на складах уже созданы, прикладная логика УТ 11 запрещает менять строки документа-распоряжения до корректировки соответствующих ордеров.

Рекомендация по сопровождению конфигурации

В типовых конфигурациях не рекомендуется напрямую редактировать типовые роли поставщика в конфигураторе, чтобы избежать проблем при последующих обновлениях. Оптимальный способ решения — создать отдельный профиль групп доступа или специализированное расширение конфигурации с дополнительной ролью, содержащей право Интерактивное изменение проведенных, и назначить этот профиль ответственным пользователям.