В конфигурации 1С:Управление торговлей редакции 10.3 часто возникает задача ограничить видимость данных для менеджеров, чтобы каждый сотрудник видел только «своих» контрагентов и документы по ним. Однако стандартная настройка через механизм RLS (Row Level Security) нередко преподносит сюрпризы: документы либо перестают проводиться, либо в списках появляются пустые строки с пометкой «Объект не найден». Рассмотрим подробно, как правильно настроить систему прав, чтобы избежать этих проблем.
Первое и самое важное правило системы прав «1С:Предприятие»: права пользователя суммируются по принципу «разрешено все, что разрешено хотя бы в одной роли». Проанализируем типичную ситуацию. Менеджеру назначены две роли: МенеджерПоПродажам и Кладовщик.
МенеджерПоПродажам настроено ограничение (RLS) на чтение документов: «Читать только те заказы, где я являюсь ответственным».Кладовщик (которую часто добавляют для корректного проведения реализации по складским регистрам) ограничения на чтение документов отсутствуют.В результате платформа видит, что через роль кладовщика пользователю разрешено читать любые документы без фильтрации. Ограничение из роли менеджера игнорируется, и пользователь видит весь список документов. Выясним, почему же в поле контрагент при этом пишется «Объект не найден»? Это происходит потому, что на справочник Контрагенты ограничение в роли менеджера все еще действует, а в роли кладовщика прав на справочник может не быть вовсе. Документ виден, а связанный с ним контрагент — скрыт защитой RLS.
Прежде чем переходить к ролям, проверим базовые настройки в пользовательском режиме. В УТ 10.3 для работы RLS необходимо использовать регистр сведений НастройкиПравДоступаПользователей. Проделаем следующие действия:
1. Перейдем в справочник «Группы доступа к контрагентам» и создадим необходимые группы (например, «Менеджеры Центрального региона», «Менеджеры Поволжья»).
2. В карточке каждого контрагента на вкладке «Прочее» укажем соответствующую группу доступа.
3. В справочнике «Группы пользователей» создадим группы и включим в них соответствующих сотрудников.
4. Через интерфейс «Настройка прав доступа» свяжем группы пользователей с группами доступа к контрагентам, установив флаги на чтение и запись.
Важно помнить: если у пользователя есть роль с Полными правами, никакие настройки RLS на него действовать не будут. Для проверки ограничений используйте только типовые роли.
Если после настройки групп доступа в журналах все равно видны «лишние» документы с надписью «Объект не найден», значит, одна из дополнительных ролей (например, Кладовщик или Пользователь) дает избыточные права на чтение. Проанализируем, как это исправить.
Откроем конфигуратор и найдем роль, которая «пропускает» лишние данные. Нам необходимо настроить ограничение доступа на уровне записей для объектов Документ.ЗаказПокупателя и Документ.РеализацияТоваровУслуг. Однако, как показывает практика, этого недостаточно. Критически важно настроить ограничения и для Журналов документов.
Рассмотрим список журналов, в которых нужно прописать условия RLS:
ЖурналДокументов.ЗаказыПокупателейЖурналДокументов.ДокументыКонтрагентовЖурналДокументов.СкладскиеДокументыЖурналДокументов.ЦенообразованиеВ каждой роли, имеющей доступ к этим журналам, на праве Чтение должно стоять условие. Обычно в УТ 10.3 используются шаблоны ограничений. Пример текста ограничения для документа или журнала по контрагенту может выглядеть так:
#Контрагент("Контрагент")
Это встроенный шаблон, который обращается к настройкам прав доступа пользователей. Его нужно скопировать из роли МенеджерПоПродажам и вставить в те же объекты роли Кладовщик.
Зачастую роль Кладовщик добавляют только потому, что без нее Реализация товаров и услуг выдает ошибку при попытке проведения. Проанализируем ситуацию: проведение затрагивает регистры накопления (например, Товары на складах, Партии товаров на складах), на которые у обычного менеджера может не быть прав.
Рекомендуемый подход: вместо того чтобы давать менеджеру широкую роль Кладовщик, которая «ломает» видимость документов, создадим новую вспомогательную роль (например, ДополнительныеПраваДляПроведения). В этой роли:
Таким образом, право на чтение документов система будет брать только из роли МенеджерПоПродажам, где RLS настроен корректно, а права на запись движений в регистры — из новой вспомогательной роли.
Если вы внесли изменения в конфигураторе или в регистре настроек, а менеджер все равно видит лишнее (или наоборот — ничего не видит), следует проверить параметры сеанса. RLS в УТ 10.3 активно кэширует данные о доступных группах пользователей.
Посмотрим на алгоритм действий при отладке:
Группы пользователей для данного сотрудника не указано несколько групп, которые могут конфликтовать (одна разрешает доступ, другая нет).Чтение ограничено через RLS, а Просмотр разрешен без ограничений, пользователь может видеть записи в динамических списках (хотя и не сможет открыть карточку документа). Ограничение RLS должно быть идентичным для обоих прав.Для того чтобы ограничение работало идеально, выполним финальную проверку по пунктам:
1. Исключение лишних ролей: У пользователя нет ролей ПолныеПрава или типовых ролей, в которых чтение документов разрешено без RLS (проверьте роль Пользователь).
2. Идентичность ограничений: Текст ограничения в поле Чтение и Просмотр одинаков для всех ролей пользователя для конкретного документа.
3. Ограничение журналов: В журналах документов прописаны те же условия RLS, что и в самих документах.
4. Доступ к регистрам: Права на проведение обеспечены через доступ к регистрам, а не через дублирование прав на чтение документов.
5. Группы доступа: Контрагенты распределены по группам, а группы привязаны к пользователям через соответствующий регистр.
Соблюдение этих правил позволит создать чистую и прозрачную систему прав в УТ 10.3, где менеджеры будут сфокусированы только на своих продажах, не отвлекаясь на документы коллег и не видя раздражающих надписей «Объект не найден».