Меню

1с настройка доступа до реквизитов

Настройка ролей и прав доступа

Область применения: управляемое приложение, обычное приложение.

Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.

1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.

Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.

Например, в УП(ERP) это роль ПартнерСамообслуживание .

1.2. Роль ПолныеПрава (англ. FullAccess ) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator ) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.

1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы ) не должна давать право на интерактивное удаление ссылочных объектов.

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

1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.

1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.

1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы , создавать отдельные роли в этом случае не требуется.

1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.

Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.

1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».

Исключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом , которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.

1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование , ТонкийКлиент и т.п.).

  • при создании новой роли нужно следить, чтобы эти права были выключены.

1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке — для ссылочных данных), а следует включать эти права в роли БазовыеПрава (англ. BasicAccess

  • ) и БазовыеПраваВнешнихПользователей (англ. BasicAccessExternalUser
  • ) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.

    1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
    Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.

    2. Правила создания ролей к элементарным функциям

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

    Пример:
    Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.

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

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

    2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.

    2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.

    3. Ссылочные объекты и регистры

    3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли

    • Чтение (англ. Read );
    • ДобавлениеИзменение (англ. InsertUpdate ) (или Изменение (англ. Update ), если добавление выполняется автоматически, либо только администратором).

    Роли должны содержать следующие права (когда они имеются у объекта метаданных):

    источник

    Права доступа на реквизиты


    Пользователь не должен видеть этот реквизит

    Предположим, что заказчик поставил перед разработчиком задачу разграничения доступа на некоторый реквизит документа. В нашем примере это будет реквизит «Комментарий» в документе «Тестовый документ». У задачи множество вариантов реализации. В статье рассмотрим вариант с использованием механизма разграничения прав на реквизиты с использованием ролей. Данная возможность появилась в платформе 1С:Предприятие 8.2.

    Настраиваем роль

    Итак, приступим. В тестовой конфигурации создадим наш «Тестовый документ» с несколькими реквизитами и три роли (см. следующий скриншот).

    Обратите внимание на роли «ДоступКомментарий» и «БезДоступаККомментарию». Обе роли имеют доступ к документу «Тестовый документ». Различие между ним лишь в настройке права доступа к реквизиту «Комментарий». На следующем скриншоте представлено различие между ними.

    Для дальнейшего тестирования создадим двух пользователей. Имена назначим в соответствии с присвоенными ролями: «Доступ к комментарию» и «Без доступа к комментарию». Теперь мы можем перейте к тестированию в режиме 1С:Предприятия.

    Тестируем

    Запустим программу в режиме 1С:Предприятие под пользователем «Без доступа к комментарию». Откроем документ и увидим результат наших действий:

    Как мы видим, реквизит «Комментарий» не отображается как в форме документа, так и в форме списка. Теперь запустим программу от имени пользователя «Доступ к комментарию». Тогда мы получим следующий результат:

    Теперь реквизит «Комментарий» доступен во всех открытых формах. В принципе, механизм работает.

    Данная настройка действует на все формы, открываемые в режиме предприятия. Но у механизма разграничения прав по реквизитам есть некоторые нюансы работы, о которых стоит упомянуть.

    Подводный камень

    Настраивать права для отдельных реквизитов очень удобно, но на самом деле этот механизм трудно отнести к настрокам прав доступа. И вот почему:

    1) Если мы попытаемся выполнить запрос к реквизиту, доступ к которому ограничен, мы все равно получим его значение без каких-либо ошибок/предупреждений платформы.

    2) При формировании SQL-запросов к базе данных в клиент-серверном варианте работы, платформа не учитывает настройки доступа на уровне реквизитов.

    На следующем скриншоте представлен текст SQL-запроса, формируемый платформой при открытии документа при обоих вариантах настройки доступа к полю «Комментарий».

    Как мы видим, в запросе присутствует выборка поля «_Fld17», в которм присутствует значение комментария.

    3) Механизм разграничения прав на уровне реквизитов работает только для управляемых форм.

    Если открыть обычную форму в управляемом или обычном приложении, то настройка прав в ролях на реквизиты объектов не будет действовать.

    Как мы видим из примера выше, обычная форма, открытая в управляемом режиме, не учитывает права доступа на отдельные реквизиты.

    Подведем итог

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

    Наиболее правильными механизмами для разраничения прав доступа на объекты конфигурации — это настрока прав на отдельные объекты в ролях и механизм RLS .

    источник

    Настройка прав доступа в 1С 8

    Вопрос о настройке прав доступа в программах 1С возникает в двух случаях:

    • руководству компании требуется ограничить пользователя в правах;
    • руководству необходимо расширить права для пользователя.

    Права пользователя в 1С

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

    При правильной настройке 1С система всегда ответит пользователю, если ему нельзя совершить то или иное действие с объектом: «у вас недостаточно прав для редактирования».

    Пошаговая настройка прав доступа в 1С

    Расскажем, как настроить права доступа на примере программы «1С:Бухгалтерия 8 редакция 3.0». Однако обратите внимание, что аналогичным образом настраиваются права доступа для пользователей и в других программных продуктах 1С. Например, инструкция также подойдет к «1С:Управление торговлей», «1С:Зарплата и управление персоналом», «1С:ERP» и другим ПП.

    Шаг №1. Настройка пользователей и прав

    В самом начале необходимо зайти в раздел настроек программы и выбрать раздел «Настройка пользователей и прав».

    Это действие можно также выполнить на вкладке «Администрирование», если у вас есть необходимые права для действий.

    Шаг № 2. Пользователи

    Для того, чтобы увидеть, к какую группу доступа входит отдельный пользователь, нужно перейти в раздел «Пользователи». Здесь можно создать нового пользователя 1С или выполнить редактирование для уже существующего или целой группы.

    Важно! Вы сможете управлять данными списками и вносить изменения только в том случае, если сами имеете права администратора.

    Чтобы создать необходимую группу пользователей, их можно выбрать из базы. Здесь нужно проверить, что установлены флажки «Вход в программу разрешен» и «Показывать в списке выбора». Если их не будет, то при авторизации пользователь себя не увидит.

    Шаг № 3. Роли для группы

    Итак, в нашей программе пользователи входят в группы с разрешенным доступом. Например, можно создать группу бухгалтеров, администраторов, кассиров, логистов и т.д. Отметим, что один и то же пользователь может относиться к нескольким разным группам. У каждой из групп прописываются роли.

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

    Чтобы узнать, какие права откроются пользователю, нужно перейти во вкладку «Описание».

    Роли могут быть базовыми, которые позволяют только просматривать документ. Могут быть специальными, когда открывается доступ для редактирования.

    Шаг № 4. Профиль групп доступа

    Допустим, что вам необходимо разрешить группе бухгалтеров редактировать реквизиты объектов. Для этого зайдите в раздел «Профиль групп доступа». Установите флажок «редактировать реквизиты объектов».

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

    Шаг № 5. Ограничение на уровне записей

    Речь идет о RLS (Record Level Security). Вы найдете необходимую колонку в «Отчете по правам пользователя», в разделе «Права доступа». Чтобы работать с ограничение на уровне записей, нужно установить соответствующий флажок во вкладке.

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

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

    Вы также можете перемещать пользователя по группам в 1С, чтобы изменить права доступа.

    Шаг № 6. Новые роли

    Чтобы не путаться в бесконечном разнообразии ролей, рекомендуем создать собственные роли. Для этого зайдите в дерево метаданных.

    Разграничить права в новой роли можно путем выставления необходимых флажков напротив нужного вам права.

    Задать ограничение можно в правом нижнем углу. Здесь работает механизм настройки прав доступа по отношению к конкретным данным.

    К примеру, вы можете ограничить изменение документа только по одной организации.

    Используйте конструктор ограничений доступа. Он поможет выбрать необходимые условия для доступа. Кроме того, программа предложит вас шаблоны ограничений, которые останется только выбрать и добавить.

    Примечание: для создания новых ролей в режиме Конфигуратора необходимо включить возможность изменения конфигурации.

    Создание новых ролей возможно так же в пользовательском режиме (с ограничениями) — см. примечание в «Шаг №4».

    Другие настройки 1С

    Итак, вы настроили все права доступа в 1С, какие требовалось. Что же еще предлагает система?

    Обратите внимание на следующие разделы:

    • «Копирование настроек»;
    • «Очистка настроек».

    Их названия говорят сами за себя. Эти настройки относятся к внешнему виду отчетов программы.

    Если вы зайдете в раздел «Настройки пользователей», то можете настроить такой внешний вид, какой вам понравится и какой будет более удобным.

    Здесь выбранный флажок «Разрешить доступ внешним пользователям» откроет возможности для внешних пользователей. Такими пользователями могут быть покупатели вашего интернет-магазина, который работает на базе 1С.

    Разработчики 1С позаботились о том, чтобы предоставить пользователям широкие возможности для администрирования прав доступа. Инструменты могут показаться непростыми. Но это только сначала. Используйте наши рекомендации и инструкцию, и тогда в вашей компании не возникнет трудностей с настройкой прав доступа пользователей к тем или иным объектам.

    Обратите внимание на то, чтобы у вас был действующий договор 1С:ИТС. Только в этом случае вы сможете пользоваться самыми актуальными данными и документами в системе 1С. Позвоните нашим специалистам и узнайте о сроке вашего договора 1С:ИТС.

    источник

  • Читайте также:  prusa i3 настройка концевиков

    Добавить комментарий

    Adblock
    detector