Защита справочников и документов от пометки на удаление

Чтобы пользователь не мог пометить объект на удаление, снимите в его роли право «Интерактивная пометка удаления» для нужных справочников и документов — команда «Пометить на удаление» у него просто исчезнет из интерфейса. Делается это в конфигураторе, в свойствах роли, и держится надёжнее любых устных договорённостей «не трогайте проведённые документы».

Классическая ситуация: бухгалтер выделил в списке десяток строк, машинально нажал Del, подтвердил — и к вечеру половина реализаций за месяц висит с перечёркнутыми значками. Физически данные ещё в базе, но отчёты уже врут, а восстанавливать пометки вручную долго. Запрет на уровне прав такую историю закрывает.

Ниже — пять рабочих способов ограничить пометку и удаление: от самого простого (права роли) до жёстких (блокировка в коде и аудит). Один запрет можно усилить другим — они не конфликтуют.

Право «Интерактивная пометка удаления» в роли

Пометка на удаление — это отдельное интерактивное право, его выдают или забирают для каждого объекта метаданных. Откройте конфигуратор, в дереве конфигурации найдите нужную роль в ветке Общие → Роли, откройте её и перейдите к списку объектов.

Для справочника или документа в колонке прав есть набор флажков. За пометку отвечают:

• 🔹 Интерактивная пометка удаления — установка пометки через команду в интерфейсе;
• 🔹 Интерактивное снятие пометки удаления — снятие пометки;
• 🔹 Интерактивное удаление помеченных — запуск обработки удаления;
• 🔹 Интерактивное удаление — немедленное удаление клавишей, минуя пометку (в типовых ролях почти всегда снято).

Чтобы запретить пометку, снимите флажок «Интерактивная пометка удаления» у выбранных объектов в этой роли. После обновления конфигурации команда «Пометить на удаление / Снять пометку» для такого пользователя станет недоступной.

Не редактируйте роли типовой конфигурации напрямую — это снимет её с поддержки и осложнит обновления. Для типовых (БП 3.0, ЗУП 3.1, УТ 11) заведите собственную роль в расширении конфигурации и настройте права в ней: расширение накладывается поверх типовой и переживает обновления.

В пользовательском режиме точечно отключить именно пометку на удаление для одного документа штатными профилями групп доступа нельзя — там права группируются крупнее. Тонкая настройка живёт в конфигураторе или в расширении.

Чтобы быстро понять, кто из пользователей сейчас может ставить пометку, посмотрите, какие роли входят в их группы доступа, и проверьте в этих ролях нужное право. Снятие права убирает именно интерактивную команду — программно (из обработки, обмена, внешней обработки с правами) пометку всё ещё можно установить. Поэтому для баз, где крутятся сторонние обработки и регламентные задания, один запрет прав дополняют блокировкой в модуле объекта (см. ниже).

Ограничение доступа к записям через RLS

Иногда задача не «запретить пометку вообще», а «пусть пользователь не трогает чужие данные». Тогда подключают ограничение доступа на уровне записей (RLS — Record Level Security).

RLS задаётся в роли на вкладке с шаблонами ограничений: вы описываете условие, по которому строки таблицы доступны пользователю. Если запись не проходит условие на изменение — пользователь её и не пометит, потому что пометка на удаление для платформы является изменением объекта.

Типовые сценарии RLS:

• доступ к документам только своей организации;
• доступ только к своему подразделению или складу;
• запрет изменения документов, проведённых до даты запрета редактирования.

Последний пункт особенно удобен: в типовых конфигурациях есть механизм «Даты запрета изменения» (раздел Администрирование → Настройки пользователей и прав). Он закрывает редактирование, проведение и пометку на удаление задним числом для выбранного периода — без правки ролей вообще.

Блокировка пометки и удаления в модуле объекта

Когда права настроить нельзя (например, пометку надо запретить только при определённом условии — документ оплачен, период закрыт), ставят программный заслон в модуле объекта.

За перехват отвечают два события:

• ПередЗаписью(Отказ) — срабатывает при любой записи, в том числе при установке пометки;
• ПередУдалением(Отказ) — срабатывает при физическом удалении объекта.

Пометка на удаление — это запись объекта с реквизитом ПометкаУдаления = Истина. Поймать именно момент установки пометки можно, сравнив новое состояние с тем, что уже лежит в базе:

Процедура ПередЗаписью(Отказ)
    Если ПометкаУдаления И Не ЭтоНовый() Тогда
        СтарыйОбъект = Ссылка.ПолучитьОбъект();
        Если Не СтарыйОбъект.ПометкаУдаления Тогда
            Отказ = Истина;
            Сообщить("Пометка на удаление этого документа запрещена.");
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Здесь ЭтоНовый() отсекает создание объекта, а повторное чтение через Ссылка.ПолучитьОбъект() даёт прежнее значение пометки: если раньше её не было, а сейчас есть — пометку только что поставили, и мы её отклоняем через Отказ = Истина.

Физическое удаление глушится проще:

Процедура ПередУдалением(Отказ)
    Отказ = Истина;
КонецПроцедуры

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

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

Контроль ссылок перед удалением

Даже если пометку разрешили, от разрушения данных защищает контроль ссылочной целостности. Платформа не даёт физически удалить объект, на который ссылаются другие — например, нельзя стереть контрагента, пока на него оформлены документы.

Этот контроль работает на этапе физического удаления помеченных объектов, а не в момент пометки. Поэтому помеченный, но «связанный» объект останется в базе: обработка удаления покажет его в списке неудаляемых и перечислит, что на него ссылается.

Полезные приёмы для проверки связей:

1. В карточке объекта откройте связанный с ней стандартный отчёт по структуре подчинённости или команду поиска ссылок (в типовых — «Ещё → Связанные документы» либо аналогичная команда в меню формы).
2. Перед массовой пометкой прогоните обработку удаления в режиме поиска, не удаляя — она соберёт ссылки и покажет, что реально можно убрать.
3. Для разовой проверки по всей базе подойдёт универсальный поиск ссылок на объект средствами платформы (НайтиПоСсылкам в коде или штатная обработка поиска ссылок).

Кто может физически удалять помеченные объекты

Пометка — это ещё не удаление. Данные исчезают только после запуска обработки «Удаление помеченных объектов». Доступ к ней и решает, кто способен стереть помеченное безвозвратно.

В типовых конфигурациях обработка лежит в разделе Администрирование → Обслуживание → Удаление помеченных объектов. Запуск её под рядовым пользователем обычно закрыт: право на это даёт административный профиль.

Чтобы физическое удаление не делал никто, кроме администратора:

• оставьте право «Интерактивное удаление помеченных» только в административной роли;
• снимите у рядовых ролей право «Удаление» на объектах — оно отвечает за программное удаление;
• запускайте очистку по регламенту, а не по требованию «мне срочно нужно место».

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

Аудит пометок и удалений в журнале регистрации

Любая пометка и любое удаление остаются в журнале регистрации — это ваш способ понять, кто и когда перечеркнул документ.

Откройте журнал: в типовых конфигурациях — через раздел Администрирование, пункт про журнал регистрации; универсально для любой базы — главное меню → Все функции → Стандартные → Журнал регистрации (команду «Все функции» предварительно включают в параметрах).

В журнале настройте отбор:

• по событию «Данные. Изменение» — так видно установку и снятие пометки (для платформы это изменение объекта);
• по событию «Данные. Удаление» — это физическое удаление;
• добавьте отбор по пользователю и по периоду, чтобы сузить выборку.

В строке события журнал показывает пользователя, дату, компьютер и сам объект. Этого достаточно, чтобы восстановить картину: кто поставил пометку, когда и на каком рабочем месте. Двойной клик по записи открывает подробности события — там же виден сеанс, из которого пришло изменение.

Журнал удобно отфильтровать по конкретному документу: откройте его из списка через команду просмотра истории или задайте отбор по данным события. Так из сотен строк остаётся только то, что касается нужного объекта, и сразу видно всю цепочку — создание, проведение, пометку и снятие пометки.

Связка «запрет прав + журнал регистрации» закрывает тему полностью: одни пользователи физически не могут пометить объект, а по остальным всегда видно, кто это сделал.

Какой способ выбрать под свою задачу

Способы не исключают друг друга — их комбинируют. Права роли отвечают «кому можно вообще», блокировка в модуле — «при каком условии», а журнал — «кто сделал». Короткая шпаргалка, с чего начать:

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

Частые вопросы