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