← На главную

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

Почему не рекомендуется изменять типовую роль ПолныеПрава

Многие начинающие разработчики сталкиваются с тем, что роль ПолныеПрава недоступна для редактирования или защищена поддержкой поставщика. Первое желание — снять роль с поддержки и отключить в ней галочки интерактивного удаления. Однако профессиональное сообщество категорически не рекомендует так поступать по ряду причин:

• Сложности при обновлении: При установке обновлений от 1С конфигурация поставщика будет сравниваться с вашей. Если вы изменили типовую роль, возникнет конфликт, который придется вручную разрешать при каждом обновлении системы.
• Риск потери настроек: Автоматическое объединение конфигураций может некорректно обработать ваши правки, что приведет к сбросу настроек прав доступа для новых объектов.
• Нарушение архитектурной логики: Роль ПолныеПрава задумывалась как роль, предоставляющая максимальный доступ. Ограничение ее функционала может привести к непредсказуемому поведению системы, если другие модули или механизмы 1С ожидают наличия у пользователя всех прав.

Стратегия создания дополнительных ролей

Наиболее надежный подход заключается в использовании механизма ролей и профилей групп доступа. Вместо модификации типовых объектов мы рекомендуем следовать стандартной методике разработки 1С:

1. Создайте собственные роли для управления доступом к новому объекту, например: ЧтениеОбъектаИмя и ДобавлениеИзменениеОбъектаИмя.
2. Настройте права в созданных ролях согласно бизнес-требованиям. В этих ролях вы можете гибко управлять правом на Интерактивное удаление, не затрагивая системные роли.
3. Сгруппируйте созданные роли в Профили групп доступа. Таким образом, вы сможете предоставлять права конкретным группам пользователей, не давая им лишних полномочий.

Использование расширений конфигурации

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

Рассмотрим пошагово, как это реализовать:

• Добавьте нужные роли в Расширение.
• Включите возможность изменения прав для объектов расширения.
• Установите необходимые ограничения для ролей в рамках расширения.

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

Рекомендации по стандартам разработки

Согласно стандартам разработки 1С, существует четкое разграничение между Удалением и Интерактивным удалением:

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

Чтобы избежать ошибок при разработке, придерживайтесь следующих правил:

• Всегда анализируйте необходимость предоставления прав пользователю. Для обычных пользователей не используйте роль ПолныеПрава.
• Для защиты данных используйте механизмы RLS (ограничение доступа на уровне записей) и правильно настроенные профили пользователей.
• Если пользователь должен иметь возможность удалять данные, предоставляйте ему доступ к типовой обработке Удаление помеченных объектов, вместо разрешения непосредственного удаления из списка.

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