Администрирование · 11 мин
Права «Изменение» и «Редактирование» в 1С: в чём отличие
Разбираем отличие прав Изменение и Редактирование в 1С: что проверяет платформа, как настроить роли, типичные ошибки и проверка результата.
В конфигураторе 1С при настройке ролей рядом стоят два похожих права — «Изменение» и «Редактирование». Из-за схожих названий их часто путают: администратор снимает не ту галочку, и пользователь либо теряет доступ к нужным документам, либо, наоборот, получает возможность менять данные, которые трогать не должен.
Разница между этими правами принципиальна: одно из них проверяется платформой при записи объекта в базу данных, а второе — только при интерактивных действиях пользователя в формах. Понимание этого различия позволяет строить корректные роли и избегать ситуаций, когда запрет в интерфейсе обходится через обработку или обмен данными.
Ниже разберём, что именно проверяет каждое право, как они работают в паре с правами «Добавление» и «Интерактивное добавление», как настроить роль под типовые сценарии и как убедиться, что ограничения действительно работают.
Что проверяет право «Изменение»
Право «Изменение» — это фундаментальное ограничение на уровне доступа к данным. Платформа проверяет его в момент записи существующего объекта в информационную базу: документа, элемента справочника, записи регистра и т.д. Если права нет, запись завершится ошибкой нарушения прав доступа независимо от того, откуда инициирована операция.
Ключевое свойство этого права — оно работает при любом способе изменения данных: через форму, программно из встроенного языка, через обмен данными, через COM-соединение или веб-сервис. Именно поэтому «Изменение» считается основным защитным барьером: сняв его, вы гарантированно закрываете возможность модификации объекта.
Обратите внимание: право «Изменение» относится к уже существующим объектам. Создание новых контролируется отдельным правом «Добавление». Поэтому роль, у которой есть «Добавление», но нет «Изменения», позволит создать документ, но не даст перезаписать его после записи — на практике такая комбинация почти всегда нежизнеспособна.
Что проверяет право «Редактирование»
Право «Редактирование» относится к группе интерактивных прав. Оно проверяется только тогда, когда пользователь работает с объектом через интерфейс: открывает форму, пытается изменить поля, сохранить документ кнопкой «Записать» или «Провести». Если права нет, форма объекта открывается в режиме просмотра — поля недоступны для ввода.
Принципиальное ограничение: «Редактирование» никак не защищает данные от программного изменения. Обработка, обмен или код внешнего соединения при наличии права «Изменение» спокойно запишут объект, даже если интерактивное редактирование пользователю запрещено. Платформа здесь исходит из логики, что интерактивные права — это лишь удобный способ «спрятать» функциональность из интерфейса.
На практике снятие «Редактирования» при оставленном «Изменении» применяется редко — например, когда данные объекта должны формироваться только автоматически (загрузкой из другой системы), а ручная правка пользователем нежелательна. Но нужно помнить: пользователь с правом «Изменение» при наличии доступа к внешним обработкам потенциально может обойти такой запрет.
Сопоставление двух прав
Проверяется при любой записи существующего объекта: из формы, из кода, при обмене. Реальный барьер защиты данных.
Проверяется только при интерактивной работе в формах. Не защищает от программного изменения и обходится обработками.
Как права работают в связке: типовые комбинации
Чтобы роль вела себя предсказуемо, права настраивают парами. Для полноценной работы пользователя с объектом обычно нужен набор: «Чтение», «Добавление», «Изменение» и их интерактивные аналоги — «Интерактивное добавление» и «Редактирование». Снятие одного элемента из цепочки даёт специфические сценарии.
Режим «только просмотр» получается, когда оставлено только «Чтение» (и «Просмотр»). Режим «просмотр и создание без правки» — теоретически возможен, но на практике неудобен: пользователь не сможет исправить собственную ошибку в только что созданном документе. Режим «программное изменение без ручной правки» — «Изменение» есть, «Редактирование» снято.
| Комбинация прав | Что может пользователь | Где применяется |
|---|---|---|
| Чтение + Просмотр | Только открывать и смотреть данные | Роли для аудиторов, руководителей |
| Чтение + Добавление + Изменение + интерактивные | Полная работа с объектами | Основные роли операторов, менеджеров |
| Чтение + Изменение, без «Редактирование» | Изменение только программно | Данные, заполняемые обменами |
| Чтение + Добавление, без «Изменение» | Создание, но не правка существующего | Редко, требует доработки процесса |
Как настроить роль: пошаговый порядок
Настройка выполняется в конфигураторе. Откройте ветку «Общие — Роли», выберите нужную роль или создайте новую, затем в правой части окна найдите требуемый объект метаданных (справочник, документ, регистр). В списке прав отметьте или снимите нужные флажки.
Если конфигурация типовая и находится на поддержке, изменение роли потребует снятия объекта с полной поддержки или включения режима изменений. Учитывайте это при планировании обновлений: доработанные роли придётся сопоставлять вручную при каждом обновлении конфигурации.
- 1Сделайте резервную копию информационной базы или работайте на копии.
- 2Откройте конфигуратор, ветка «Общие — Роли», выберите роль.
- 3Найдите объект метаданных и установите права: «Чтение», «Изменение», «Редактирование» по сценарию.
- 4Обновите конфигурацию базы данных (F7).
- 5Войдите под тестовым пользователем с этой ролью и проверьте поведение.
После изменения ролей не забудьте обновить конфигурацию базы данных — иначе изменения не вступят в силу. Пользователям, уже работающим в системе, может потребоваться перезайти в сеанс, чтобы новые права применились.
Как проверить, что ограничения работают
Проверку выполняйте на тестовом пользователе, которому назначена только проверяемая роль. Сначала откройте объект интерактивно: форма должна открываться в режиме просмотра, если «Редактирование» снято, а кнопки «Записать» и «Провести» — недоступны или завершаться ошибкой права доступа.
Затем проверьте программный сценарий, если снято «Изменение»: попытка записать объект из обработки или консоли кода должна завершаться исключением «Нарушение прав доступа». Если запись проходит — значит, у пользователя есть другая роль, дающая это право, либо код выполняется в привилегированном режиме.
Как проверить результат
Форма открывается на просмотр, поля недоступны
Поля редактируются и объект сохраняется
Ошибка «Нарушение прав доступа» при снятом «Изменении»
Объект записывается без ошибок
Только целевая роль, без дублирующих
Назначены роли, перекрывающие ограничение
Типичные ошибки при настройке
Самая частая ошибка — снятие только «Редактирования» с целью «запретить менять данные». Пользователь действительно не сможет править объект в форме, но любая обработка, обмен или программный вызов запишут данные без помех. Для реального запрета снимать нужно «Изменение».
Вторая ошибка — забыть про совокупность ролей. В 1С права суммируются: если хотя бы одна из назначенных пользователю ролей даёт право «Изменение», ограничение в другой роли не сработает. Проверяйте полный список ролей пользователя, включая стандартные роли типовой конфигурации.
Третья группа ошибок связана с привилегированным режимом и правами на связанные объекты. Код, выполняемый в привилегированном режиме (например, при проведении документа), не проверяет права — поэтому запреты на уровне ролей не остановят регламентные операции. А запрет на изменение документа не отменяет необходимости отдельно ограничивать права на его движения и связанные регистры, если к ним есть прямой доступ.
Когда каких прав недостаточно: RLS и дополнительные механизмы
Права «Изменение» и «Редактирование» действуют на весь объект метаданных целиком: нельзя с их помощью разрешить менять одни документы и запретить другие внутри одного вида. Для таких сценариев используется ограничение доступа на уровне записей (RLS) — например, разрешить менеджеру редактировать только документы своей организации или своего склада.
RLS настраивается в той же роли на закладке «Шаблоны ограничений» и вкладке прав с полем «Ограничение доступа». Учтите, что RLS заметно усложняет запросы платформы и может влиять на производительность, поэтому шаблоны стоит писать аккуратно и тестировать на реальных объёмах данных.
Как выбрать механизм ограничения
Что важно запомнить
«Изменение» — реальный барьер на запись объекта, действует всегда. «Редактирование» — только интерфейсное ограничение, которое не защищает от программных изменений. Права по ролям суммируются, поэтому проверяйте весь набор ролей пользователя и тестируйте результат на копии базы.
Чем «Редактирование» отличается от «Просмотра»?
«Просмотр» управляет доступностью команд открытия списков и форм объекта в интерфейсе, а «Редактирование» — возможностью менять данные в открытой форме. Без «Просмотра» пользователь вообще не увидит объект в меню, без «Редактирования» — откроет его только для чтения.
Если снять «Изменение», сможет ли пользователь провести документ?
Нет. Проведение — это запись документа и его движений, поэтому без права «Изменение» (а также прав на соответствующие регистры) проведение завершится ошибкой нарушения прав доступа.
Почему запрет не срабатывает, хотя в роли всё снято?
Чаще всего у пользователя назначена ещё одна роль, дающая нужное право: права в 1С суммируются по всем ролям. Также проверьте, обновлена ли конфигурация базы данных и не выполняется ли операция в привилегированном режиме.
Действуют ли эти права при обмене данными между базами?
Да, право «Изменение» проверяется и при загрузке данных обменом — от имени пользователя, под которым выполняется обмен. «Редактирование» при обмене не проверяется, так как это интерактивное право.
Можно ли запретить редактирование только проведённых документов?
Штатными правами роли — нет: «Изменение» действует на все объекты вида. Такие сценарии реализуют через дату запрета изменения данных, подписки на события записи или RLS с условием по состоянию документа.
Нужно ли перезапускать сеансы пользователей после смены ролей?
После обновления конфигурации базы данных новые права применяются к новым обращениям, но надёжнее попросить пользователей перезайти в программу — это исключает работу с устаревшим кэшем прав в открытом сеансе.