Мы сталкиваемся с типичной задачей в 1С:УТ11, когда необходимо строго регламентировать доступ менеджеров к контрагентам. Требуется, чтобы каждый менеджер видел только тех контрагентов, которые относятся к его зоне ответственности, и при этом имел ограниченные права на редактирование – например, только возможность изменять контактную информацию (адреса и телефоны), оставляя остальные данные в режиме просмотра. Подобные ограничения критически важны для обеспечения безопасности данных и разграничения обязанностей в крупных компаниях. Рассмотрим, как мы можем решить эту проблему, используя механизмы RLS и точечную настройку прав доступа.
RLS (Row-Level Security) в 1С – это мощный инструмент, позволяющий ограничить доступ пользователей не просто к объекту целиком (например, справочнику "Контрагенты"), а к конкретным записям внутри этого объекта. Это особенно актуально для компаний с большим штатом, где каждый сотрудник должен работать только со своей частью данных.
Механизм RLS интегрирован в стандартную систему назначения прав пользователей и построен по цепочке: роль → профиль группы пользователя → группа доступа → пользователь. Он включается в "НСИ и администрирование – Администрирование – Настройка пользователей и прав – Группы доступа" с помощью функциональной опции "Ограничивать доступ на уровне записей". Для его корректной работы часто требуется регламентное задание "Заполнение данных для ограничения доступа" (для производительного варианта работы).
Отладка RLS может быть неочевидной, так как платформа 1С не предоставляет прямого инструмента. Однако мы можем использовать универсальную консоль отчетов (версия не ниже 2.6.9.2). На закладке "Данные" этой консоли есть функция "Выполнить от имени". Она позволяет выполнить SQL-запрос под правами конкретного пользователя, не запуская дополнительную сессию. Это дает нам возможность наглядно увидеть, какие записи будут доступны этому пользователю, и проверить корректность работы RLS-фильтров. Существуют также внешние обработки и подсистемы "Инструменты разработчика", которые помогают анализировать и отлаживать запросы RLS, парсить их и проверять права на таблицы.
Одна из самых распространенных причин, по которой RLS может не срабатывать, заключается в том, что пользователю выдана роль без каких-либо ограничений RLS, или же пользователь входит в несколько групп доступа, и одна из них предоставляет более полные права на объект. В таком случае, более широкие права "перекрывают" ограничения, и менеджер видит всех контрагентов, а не только своих.
Проверяем роли с полными правами: Мы должны убедиться, что ни одна из ролей, назначенных менеджеру, не дает "Полные права" (FullAccess) или не является "АдминистраторомСистемы". Такие роли предоставляют неограниченный доступ ко всем объектам, игнорируя любые настройки RLS. Если у пользователя есть такая роль, все ограничения будут проигнорированы.
Анализируем все группы доступа: Мы должны тщательно проверить все группы доступа, в которые входит менеджер. Если хотя бы одна из них предоставляет доступ к "Контрагентам" или "Партнерам" без RLS-ограничений, то менеджер будет видеть всех контрагентов. Принцип работы RLS таков, что если у пользователя есть хоть одно разрешение на чтение объекта без ограничений, то он получит полный доступ.
Настраиваем RLS-шаблоны в расширении: Если вы используете расширение для тонкой настройки прав, как предложено в сообщении 1, нам необходимо убедиться, что шаблоны RLS прописаны корректно и привязаны к группам доступа или менеджерам. Важно, чтобы ограничение применялось к нужным объектам (Справочник.Партнеры, Справочник.Контрагенты) и использовало правильные параметры фильтрации.
Пример шаблона, который может быть использован для ограничения доступа:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
#ПоЗначениямРасширенный( "Справочник.Партнеры", "Чтение", "",
"ЛЕВОЕ СОЕДИНЕНИЕ Справочник.КонтактныеЛицаПартнеров КАК Т1 ПО Т1.Владелец = Т.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ВнешниеПользователи КАК Т2 ПО Т2.ОбъектАвторизации = Т1.Ссылка",
"",
"ВнешниеПользователи", "Т.ссылка","ИЛИ",
"ВнешниеПользователи", "Т2.Ссылка", "", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","", "","","")
#КонецЕсли
Этот пример демонстрирует сложную логику, где доступ к партнерам (контрагентам) может быть ограничен через связанные контактные лица и внешних пользователей. Важно адаптировать этот шаблон под вашу специфическую структуру данных и способ привязки контрагентов к группам доступа или ответственным менеджерам. Если в вашей базе используется ограничение по группам доступа, как упомянул автор, то шаблон RLS должен обращаться именно к этим группам.
Используем настройки RLS в УТ11: В самой УТ11 функционал ограничения по подразделениям или организациям включается в "НСИ и администрирование – Настройки пользователей и прав" и далее в группах доступа на вкладке "Ограничения доступа". Здесь мы можем задать фильтрацию данных, видимых конкретному пользователю. Мы можем создать роли для каждого филиала или группы менеджеров и настроить доступ к данным только для их зоны ответственности. Например, "Менеджер по продажам (Филиал 1)" будет иметь доступ только к данным клиентов и сделок филиала 1.
Основная сложность здесь заключается в том, что права на изменение объекта в 1С по умолчанию распространяются на все его реквизиты, если явно не заданы ограничения на уровне реквизитов. Это означает, что если у пользователя есть хоть одна роль с правом изменения справочника "Контрагенты", он, скорее всего, сможет изменять все его реквизиты, даже если в других ролях эти реквизиты были отключены. Необходимо провести детальный анализ и, возможно, применить программные ограничения.
Открываем окно "Все роли": Это критически важный инструмент для нашего анализа. Для того чтобы его открыть, в конфигураторе нажмите правой кнопкой мыши по ветке "Роли" и выберите соответствующий пункт из контекстного меню.
В этом окне мы увидим сводную информацию о том, какие права даны на каждый реквизит справочника "Контрагенты" и "Партнеры" различными ролями. Важно выявить все роли, которые предоставляют право на изменение (Изменение) или добавление (Добавление) для реквизитов "Контрагента", особенно если они не относятся к контактной информации. Мы увидим, какие роли предоставляют доступ к изменению конкретных реквизитов, даже если эти роли, на первый взгляд, не имеют отношения к контрагентам.
Атомарность ролей: При создании ролей следует стремиться к их "атомарности". То есть, каждая роль должна давать права на доступ к минимальному, элементарному набору функций или данных. Из этих элементарных ролей мы формируем профили пользователей, комбинируя необходимые права. Такой подход позволяет избежать выдачи избыточных прав.
Пересмотр существующих прав:
Определите, какие роли дают право на изменение "Контрагентов" и "Партнеров". Возможно, у менеджера есть роли, которые были созданы для других целей, но случайно предоставляют избыточные права. Проверьте все роли, назначенные менеджеру через его профиль группы доступа.
В каждой такой роли проверьте права на уровне реквизитов. Хотя 1С не позволяет напрямую установить право "только на один реквизит" через стандартный интерфейс прав, мы можем влиять на это через общие права на объект. Если у пользователя есть хоть одна роль с общим правом "Изменение" для справочника, то RLS на реквизиты не поможет. Наша задача — убедиться, что ни одна из ролей не предоставляет общих прав на изменение, которые перекрывают наши попытки ограничить доступ.
Используем расширение для точечного управления: Для детального управления доступностью полей и вкладок в формах элементов справочника мы можем использовать расширения конфигурации. В расширении мы можем перехватить обработку формы на сервере, например, ПриСозданииНаСервере или ПриОткрытии для управляемой формы элемента справочника "Контрагенты" или "Партнеры". В этом обработчике мы можем программно блокировать доступ к нежелательным вкладкам или полям, делая их недоступными для редактирования (свойство ТолькоПросмотр = Истина) или даже невидимыми (свойство Видимость = Ложь) для менеджеров.
Пример псевдокода для реализации ограничения в расширении (идея из сообщения 0):
// В модуле формы элемента Контрагента/Партнера в расширении
&Перед("ПриСозданииНаСервере")
Процедура ПриСозданииНаСервере_Расширение(Отказ, СтандартнаяОбработка)
// Если текущий пользователь - менеджер и ему нужно ограничить права
// Мы можем проверить роль пользователя или его принадлежность к группе доступа
Если РольДоступна("МенеджерОграниченный") ИЛИ ПользовательВГруппеДоступа("Менеджеры") Тогда
// Проверяем, что это форма элемента Контрагента/Партнера
Если ТипЗнч(Объект) = Тип("СправочникОбъект.Контрагенты") ИЛИ ТипЗнч(Объект) = Тип("СправочникОбъект.Партнеры") Тогда
// Блокируем вкладки, кроме "Адреса и телефоны"
// Для этого мы должны знать имена групп элементов формы.
// Например, если есть группа "ОсновнаяИнформация", "Дополнительно", "БанковскиеСчета"
Если Элементы.Есть("ГруппаОсновное") Тогда
Элементы.ГруппаОсновное.ТолькоПросмотр = Истина;
КонецЕсли;
Если Элементы.Есть("ГруппаДополнительно") Тогда
Элементы.ГруппаДополнительно.ТолькоПросмотр = Истина;
КонецЕсли;
// И так далее для всех групп, которые не должны быть редактируемы.
// Также можно скрывать поля или делать их только для просмотра по отдельности.
Если Элементы.Есть("Наименование") Тогда
Элементы.Наименование.ТолькоПросмотр = Истина;
КонецЕсли;
// Убедимся, что группа "Адреса и телефоны" доступна для редактирования.
// Предполагаем, что есть такая группа элементов формы.
Если Элементы.Есть("ГруппаАдресаТелефоны") Тогда
Элементы.ГруппаАдресаТелефоны.ТолькоПросмотр = Ложь;
Иначе
// Если нет отдельной группы, нужно пройтись по реквизитам
// Например, поля "Адрес", "Телефон", "ЭлектроннаяПочта"
Если Элементы.Есть("Адрес") Тогда
Элементы.Адрес.ТолькоПросмотр = Ложь;
КонецЕсли;
Если Элементы.Есть("Телефон") Тогда
Элементы.Телефон.ТолькоПросмотр = Ложь;
КонецЕсли;
// И так далее для всех полей контактной информации
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Помните, что такой подход требует аккуратной работы с именами элементов формы (которые можно посмотреть в конфигураторе в дереве элементов формы) и тщательного тестирования, чтобы не заблокировать необходимые функции или не создать непредвиденных ошибок. Также учтите, что программное изменение свойств формы только скрывает или блокирует элементы на интерфейсе, но не отменяет права на изменение данных на уровне объекта. Поэтому критически важно сначала правильно настроить RLS и права на роли, а уже потом использовать расширения для доработки интерфейса.
Решение задачи по ограничению доступа менеджеров к контрагентам в 1С:УТ11 – это комплексный процесс, который требует внимательного подхода к настройке прав и, возможно, доработки с использованием расширений.
Тщательная проверка ролей и профилей: Всегда начинайте с аудита всех ролей и групп доступа, назначенных пользователю. Избыточные права – самая частая причина проблем с RLS. Убедитесь, что нет ролей с "Полными правами" или "АдминистраторСистемы", а также групп доступа, которые случайно предоставляют полный доступ.
Отладка RLS через консоль отчетов: Активно используйте функцию "Выполнить от имени" в универсальной консоли отчетов для проверки корректности фильтрации данных, генерируемой RLS. Это поможет вам увидеть, какие записи действительно доступны пользователю.
Окно "Все роли" – ваш помощник: Это незаменимый инструмент для анализа прав на уровне реквизитов. Используйте его, чтобы выявить все роли, которые дают право на изменение реквизитов контрагента, и скорректируйте их при необходимости.
Расширения для точечных изменений: Для детального управления доступностью полей и вкладок в формах элементов справочника, используйте расширения конфигурации и перехват событий форм (ПриСозданииНаСервере, ПриОткрытии). Это позволяет программно управлять элементами формы, делая их только для просмотра или скрывая.
Помните, что комплексное решение задачи требует не только настройки RLS и ролей, но и возможной доработки интерфейса через расширения, чтобы обеспечить максимально точное соответствие бизнес-требованиям по ограничению доступа.