Рекомендации по настройке прав
- Александр Анисков
Профили групп доступа
Профили групп доступа могут быть настроены по следующей логике:
По виду деятельности отдельных специалистов. Например: кассир, бухгалтер ТМЦ и т.д.
По особенным операциям в программе. Например: загрузка из Биллинга, просмотр данных Биллинга и т.д.
По важным видам доступа. Например: открытие внешних обработок, вывод на печать, обмен данными и т.д.
Поскольку группы могут быть скомбинированы, следует придерживаться логики, при которой перекрестные доступы реализуются путем включения пользователя в несколько групп.
Например: необходимо бухгалтеру “А” предоставить доступ к выводу данных (на печать), а бухгалтеру “Б” такой доступ ограничить. Следовательно, у вас должно быть минимум 2 профиля групп доступа:
Бухгалтер
Вывод на печать
При этом бухгалтер “А” будет включен в оба профиля, а бухгалтер “Б” только в один.
Поставляемые профили групп доступа
В программе существуют “поставляемые профили групп доступа”. В списке они никак не отличаются от созданных вручную. Но при этом изменять их состав невозможно (при открытии формы, выбор ролей будет заблокирован).
Не рекомендуется использовать поставляемые профили групп доступа.
Во-первых, поставляемые профили содержат достаточно большой набор включенных ролей. Во-вторых, при необходимости ограничить набор прав, этого сделать не получится.
По этой причине рекомендуется создавать собственные профили групп доступа (например путем копирования поставляемых) и использовать их для дальнейшей работы.
Небольшие профили, ограничивающие особенные права можно не трогать, до момента, когда их функционал не будет устраивать.
Реализация собственных прав доступа
Для реализации собственной логики распределения прав доступа, рекомендуется использовать комбинацию типовых и собственных ролей. То есть удалять права на отдельные объекты метаданных из типовых ролей, после чего добавлять отдельные роли для данных прав. После этого собственная роль может быть добавлена в необходимые профили или включена в состав новых профилей групп доступа.
Пример изменения логики работы
Например нам необходимо ограничить доступ пользователей к документам “Реализация товаров и услуг”, у которых реквизит “УВК_ВнешнийКлюч” заполнен.
В нашем примере, это документы загруженные из биллинга. Поскольку созданные вручную имеют пустой ключ.
Для начала определимся с ролями, которые имеют доступ к документу “Реализация товаров и услуг”. Для этого в меню “Дополнительный функционал” добавлена обработка “Просмотр и редактирование прав”
В открытом окне, на закладке “Отбор по метаданным” устанавливаем галку на интересующем нас объекте. В данном случае, это документ “РеализацияТоваровУслуг” (это имя документа как оно задано в конфигураторе). Нажимаем “Сформировать отчет” → “Получить роли”.
В получившемся отчете, нас интересуют первые 4 колонки прав: Чтение, Добавление, Изменение, Удаление.
Как правило право “Удаление” не даются в обычные роли, и присутствует только в роли для администрирования. Это связано с тем, что удаление данных реализуется на сервере, требует затрат времени и рекомендуется настраивать на выполнение в фоновом режиме.
А также во избежание человеческой ошибки, когда у пользователя окажется право удалять объект данных. Поскольку в таком случае есть риск, что удаление пройдет без контроля ссылочной целостности.
И так, нам необходимо в типовых ролях:
ДобавлениеИзменениеДанныхБухгалтерии
ДобавлениеИзменениеРеализацииТоваровУслуг
ЧтениеДанныхБухгалтерии
ЧтениеРеализацииТоваровУслуг
ограничить доступ к объекту “Реализация товаров и услуг”.
Для этого мы добавляем данные роли в расширение и изменяем настройку роли
Обратите внимание, в отличие от основной конфигурации, настройка роли в расширении имеет три варианта значения галочки на праве:
черная галочка на белом поле - включить право
бежевая галочка на бежевом поле - наследовать настройку из основной конфигурации
отсутствие галочки - отключить право
В нашем случае, мы не хотим полностью отключать право, чтобы не создавать отдельную роль. Поэтому мы используем механизм ограничения доступа на уровне записей (RLS) (подробнее читайте в официальной документации по платформе на сайте https://its.1c.ru/).
Для этого мы включим напрямую право “Чтение” и в ограничение доступа к данным пропишем условие:
РеализацияТоваровУслуг ГДЕ РеализацияТоваровУслуг.УВК_ВнешнийКлюч = ""То есть мы поставим отбор по всем документам для которых ключ пустой. То есть они были созданы пользователями (а не методом загрузки из Биллинга).
По итогу: если у пользователя стояла данная роль, после установки расширения, документы Биллинга ему будут более недоступны на чтение (то есть не видны в списке, а в отчетах будут значения “объект не найден”).
Не самый лучший вариант. Во-первых мы ограничили только чтение, то есть добавление и изменение (программное) будет возможно. Во-вторых, в отчетах (как написано ранее) объекты будут иметь представление “Объект не найден (…)”. Это некрасиво. Поэтому, надо сделать следующее:
для ограничения возможности добавления и изменения аналогичные доработки внести в соответствующие пункты прав
для возможности просматривать (без добавления/изменения) документов, лучше создать собственную роль “Чтение реализации из Биллинга” где сделать настройку, позволяющую только читать документы Биллинга
добавить роль “ДобавлениеИзменениеРеализацииИзБиллинга” для возможности читать, добавлять и изменять документы где УВК_ВнешнийКлюч будет заполнен. То есть из биллинга.
Таким образом, мы сможем решить все варианты задач:
операционисту мы дадим типовую роль, и документы Биллинга не будут ему мешать
бухгалтеру по реализации мы дадим типовую роль + роль чтения документов биллинга, чтобы он мог видеть все документы
бухгалтеру ответственному за загрузку данных из биллинга, мы дадим типовую роль + роль добавления/изменения документов биллинга, чтобы он мог загружать данные и видеть все документы, для сверки с целью исключения ошибок дублирования (с ручными документами)
Обратите внимание. Мы ограничивали доступ только к самим объектам. То есть в интерфейсе они будут видны, но при переходе к ним пользователь может получить сообщение “Недостаточно прав доступа” или другое сообщение об ограничении прав доступа.
Отключение объектов из интерфейса (чтобы не было видно прямо в меню и т.д.) требует достаточно большого количества заимствований в расширение, что потенциально снижает его возможность беспроблемного применения при обновлении.
Поэтому, мы рекомендуем ограничивать права именно на объекты метаданных (справочники, документы и т.д.) и не трогать интерфейсную часть программы. Или делать это только в особенных случаях. И возможно, стоит в таких случаях рассмотреть реализацию собственного интерфейса, для замены штатному. Но это “совсем другая история”.