При создании новых документов в системе 1С и попытке настроить для них права доступа, аналогичные типовым, пользователи часто сталкиваются с ситуацией, когда автоматически появляются нежелательные права. Это происходит из-за сложной логики взаимосвязанности прав доступа, заложенной в платформе 1С:Предприятие. Давайте подробно разберем, почему возникает эта проблема и какие шаги мы можем предпринять для ее решения.
Начнем с фундаментальных принципов работы системы прав доступа в 1С. В основе всего лежит концепция Ролей, которые определяют, какие действия разрешены пользователю с различными объектами конфигурации (документами, справочниками, отчетами и т.д.). Каждому пользователю может быть назначена одна или несколько ролей, и именно их совокупность определяет окончательный набор доступных действий.
Главная особенность, с которой мы сталкиваемся в нашем случае, это взаимосвязанные права. Платформа 1С спроектирована таким образом, что некоторые права доступа логически зависят друг от друга. Например, невозможно разрешить Изменение объекта без права на его Чтение, ведь для изменения данные сначала должны быть доступны для просмотра. Аналогично, право на Интерактивное удаление (то есть удаление через пользовательский интерфейс, например, пометка на удаление) всегда подразумевает наличие базового права на Удаление и часто связано с правом на Редактирование. Об этом нам напоминает пользователь в сообщении 2, а затем детализирует в сообщении 5, указывая, что отмена права Интерактивное удаление помеченных может повлечь за собой отмену связанного права, например, Редактирование.
Еще один важный аспект – это принцип кумулятивности. Если пользователю назначено несколько ролей, то доступ к любому объекту или действию будет разрешен, если хотя бы одна из этих ролей предоставляет соответствующее право. Запрет же возможен только в том случае, если все назначенные роли явно запрещают данное действие. Это означает, что даже если мы пытаемся убрать какое-то право в одной роли, оно может продолжать действовать, если у пользователя есть другая роль, которая это право предоставляет.
Наш пользователь столкнулся с этой проблемой в типовой конфигурации «Зарплата и Кадры для государственных организаций Казахстана, редакция 1.0», работающей на платформе 1С:Предприятие 8.3 (8.3.16.1224). Типовые конфигурации, особенно такие сложные, как ЗКГУ, часто имеют свою специфическую логику управления правами, которая может отличаться от базовых принципов платформы, добавляя свои слои зависимостей.
В процессе обсуждения на форуме (сообщение 4) было предложено рассмотреть флаг «Независимые права подчиненных объектов». Давайте подробнее разберем, что это за флаг и в каких случаях он применяется.
Этот флаг находится в конфигураторе при настройке прав для ролей и определяет, как система будет обрабатывать права на подчиненные объекты (например, реквизиты, табличные части, команды) относительно прав их родительского объекта (например, документа, справочника).
Если флаг установлен в положение «Истина» (галка стоит): В этом случае система будет рассматривать права подчиненного объекта независимо от прав родительского. Это означает, что если у родительского объекта (документа) нет права на изменение, но у его реквизита установлен флаг на изменение, то реквизит можно будет изменять. Этот режим полезен, когда нам нужно очень тонко настроить доступ к отдельным полям или частям объекта, не давая при этом полных прав на весь объект.
Если флаг снят (галки нет): Права подчиненного объекта будут анализироваться с учетом прав родительского. Если у родительского объекта нет какого-либо права (например, права на чтение), то и у подчиненного объекта этого права не будет, независимо от того, как оно настроено в его собственной карточке прав. Это режим по умолчанию, который обеспечивает более строгую иерархию прав.
Как отметил наш пользователь в сообщении 6, попытка использования этого флага не решила его проблему – галка Редактирование все равно устанавливалась, и при снятии ее снималась также галка Интерактивное удаление помеченных. Это подтверждает, что в данном случае мы имеем дело с более глубокой системной взаимосвязью прав, которая не отключается напрямую через этот флаг.
Методические рекомендации 1С по использованию этого флага обычно предписывают следующий порядок:
Для новых ролей рекомендуется устанавливать флажок «Устанавливать права для реквизитов и табличных частей по умолчанию» и снимать флажок «Независимые права подчиненных объектов». Это обеспечивает стандартное, иерархическое наследование прав.
Если же наша задача состоит в том, чтобы установить права только на отдельные поля объекта, но не на сам объект в целом, то сначала мы устанавливаем флажок «Независимые права подчиненных объектов». Затем мы снимаем флажок «Устанавливать права для реквизитов и табличных частей по умолчанию» и при этом очищаем права на все реквизиты и табличные части. После этого мы можем выборочно установить необходимые права только для тех реквизитов, к которым нужен доступ.
Важно понимать, что флаг «Независимые права подчиненных объектов» регулирует взаимодействие прав между родительским и дочерними элементами в иерархии конфигурации. Он не отменяет логическую взаимосвязь между *разными типами* прав на *один и тот же объект* (например, Чтение и Изменение для документа в целом), которая заложена на уровне платформы.
Учитывая выявленные особенности платформы и опыт пользователя, мы должны подойти к настройке прав комплексно. Рассмотрим шаги, которые помогут нам разобраться в этой сложной ситуации и добиться желаемого результата, максимально приближенного к типовой конфигурации.
Прежде всего, нам необходимо понять, как права настроены в типовом документе, который мы берем за образец. Для этого мы можем:
Проанализировать роли: Выяснить, какие роли назначаются пользователям, имеющим доступ к типовому документу, и какие права на этот документ установлены в каждой из этих ролей. Обратите внимание на наличие других ролей, которые могут давать "лишние" права по принципу кумулятивности.
Использовать отчет по правам доступа: В современных версиях 1С:Предприятие 8.3 (особенно в конфигурациях, использующих подсистему "Управление доступом") существует отчет, который позволяет увидеть полные права конкретного пользователя на конкретный объект, учитывая все назначенные ему роли. Найдите его в разделе администрирования или настройки прав. Это поможет нам увидеть конечный результат действия всех ролей.
Мы уже выяснили, что права Чтение, Изменение, Добавление, Удаление, Интерактивное удаление тесно связаны. Нам нужно принять это как данность платформы. Если наша задача – разрешить интерактивное удаление помеченных, но запретить редактирование, это может быть фундаментальным противоречием в логике платформы для данного типа объекта. В некоторых случаях, когда типовая конфигурация позволяет такую "странную" комбинацию прав (как в исходном сообщении), это может быть реализовано через:
Дополнительные ограничения прав на уровне кода (RLS): Некоторые типовые конфигурации, включая ЗКГУ, используют механизм ограничений прав на уровне записей (Record Level Security - RLS). Это программные алгоритмы, которые донастраивают права, указанные в ролях, ограничивая доступ к данным в зависимости от условий (например, по подразделению, организации, ответственному лицу). Если типовой документ имеет такую специфическую настройку, она не будет напрямую видна в карточке роли и потребует изучения кода конфигурации.
Специфическая логика конфигурации: Например, в конфигурациях, подобных «1С:Документооборот» или «1С:Зарплата и управление персоналом КОРП» (ЗУП КОРП), может быть реализован принцип автоматического назначения прав на документы тем, кто с ними связан (создатель, ответственный, участники проекта). В ЗКГУ для расчетных документов также могут быть свои особенности.
Хотя этот флаг не решил проблему автора с взаимосвязанностью базовых прав на документ (Редактирование и Интерактивное удаление помеченных), он все же очень полезен для более тонкой настройки прав на реквизиты и табличные части нового документа. Если вам нужно дать доступ только к части полей документа, следуйте рекомендациям 1С:
Создайте новую роль или измените существующую.
Для вашего нового документа в этой роли снимите флажок «Устанавливать права для реквизитов и табличных частей по умолчанию».
Установите флажок «Независимые права подчиненных объектов» для вашего нового документа.
После этого вы сможете выборочно настроить права на чтение/изменение для каждого реквизита и каждой табличной части документа, независимо от прав на сам документ.
Помните, что этот механизм не решает проблему базовых прав на объект в целом, но позволяет гибко управлять доступом к его составным частям.
В современных конфигурациях 1С 8.3 для упрощения администрирования прав мы активно используем Профили групп доступа и Группы доступа. Это позволяет объединять набор ролей в готовые профили и назначать их пользователям, что значительно упрощает управление большим количеством пользователей и ролей. Всегда анализируйте права пользователя через эти механизмы.
1C:Enterprise Development Tools (EDT) является мощным инструментом для разработки и анализа конфигураций. В EDT мы можем:
Просматривать детальные настройки прав ролей: EDT позволяет наглядно видеть, какие права на какие объекты установлены в каждой роли. Это более удобно, чем работа в конфигураторе 1С:Предприятие.
Анализировать метаданные: Мы можем изучить структуру нового документа и сравнить ее со структурой типового, чтобы выявить возможные различия, которые влияют на права.
Работать с конфигурацией: Хотя пользователь в сообщении 9 справедливо отмечает, что простое исправление файлов конфигурации не годится для типовых решений (особенно при последующих обновлениях), EDT является основным инструментом для внесения изменений в конфигурацию. Если вы вынуждены модифицировать типовую конфигурацию для достижения специфической комбинации прав, делайте это максимально аккуратно и с пониманием последствий для обновлений.
Напоминаем, что прямое редактирование файлов конфигурации без использования инструментария 1С (конфигуратора или EDT) является крайне нерекомендуемой практикой и может привести к неработоспособности системы.
Существует важная рекомендация относительно флага «Устанавливать права для новых объектов». Этот флаг должен быть установлен только для роли «ПолныеПрава». Для всех остальных ролей его следует снимать. Это предотвращает автоматическое предоставление прав на новые объекты всем подряд ролям и позволяет нам контролировать права более гранулярно.
Проблема, с которой мы столкнулись, является классическим примером сложности управления правами доступа в 1С, особенно когда речь идет о типовых конфигурациях и взаимосвязанности прав. Если типовой документ позволяет иметь право на интерактивное удаление без права на редактирование, это может быть следствием:
Специфических ограничений RLS, которые действуют на уровне кода для этого конкретного документа.
Уникальной логики конфигурации, которая переопределяет стандартное поведение платформы для данного объекта.
"Глюка" или непреднамеренной особенности, как предположил пользователь в сообщении 2 и 13.
Для нашего нового документа мы, скорее всего, будем вынуждены следовать стандартной логике платформы, которая требует наличия права на Изменение, если нам необходимо право на Интерактивное удаление помеченных. Если же нам критически важно воспроизвести именно такую "нестандартную" комбинацию, то нам придется идти по пути глубокого анализа кода типовой конфигурации и, возможно, создания своих собственных программных ограничений (RLS) для нового документа, что является достаточно трудоемкой задачей и требует квалификации разработчика.
В любом случае, для точной настройки прав требуется глубокий анализ всех назначенных ролей, их взаимодействия, а также понимание логики типовой конфигурации. Используйте все доступные инструменты: отчеты по правам доступа, возможности EDT, и всегда тестируйте изменения на тестовой базе перед внедрением в рабочую.