Область применения: управляемое приложение, обычное приложение.
Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.
1. Общие положения
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<LibraryName>) и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки> (англ. BasicAccessExternalUser<LibraryName>) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
3.2. Необходимо помнить, что для регистров, подчиненных регистратору, обычно не требуется назначать права на изменение (см. п. 1.7).
4. Журналы документов
4.1. Если все документы, входящие в журнал, отнесены к одной элементарной функции, то права на чтение и просмотр журнала нужно включить во все роли этой функции.
4.2. Платформа 1С:Предприятие имеет следующую особенность: если у пользователя нет прав на чтение любого документа, входящего в журнал документов, то платформа не дает доступ ко всем графам журнала, в котором отражается этот документ, для всех документов, входящих в журнал. Поэтому нет никакого практического смысла создавать отдельную роль для доступа к журналу: журнал может входить в элементарную функцию, или может быть доступен только пользователю с полными правами.
5. Константы
5.1. Если предполагается, что константа должна изменяться только администратором системы, то права на изменение и редактирование должны быть только у одной из ролей: ПолныеПрава или АдминистраторСистемы. Эти роли должны включать также и права на чтение и просмотр констант.
5.2. Если предполагается, что константу может менять пользователь, то нужно включить права на чтение, просмотр, изменение и редактирование в уже имеющуюся «настроечную» роль или создать отдельную роль Изменение<ИмяКонстанты> (англ. Edit<ConstantName>), дающую права на чтение, просмотр, изменение и редактирование этой константы.
5.3. В подавляющем большинстве случаев константа используется для хранения неконфиденциальной информации, поэтому права на чтение и просмотр константы нужно назначать роли БазовыеПрава<ИмяБиблиотеки> и БазовыеПраваВнешнихПользователей<ИмяБиблиотеки>. Это позволяет избежать неоправданной установки привилегированного режима при чтении значения константы из кода.
5.4. В редких случаях, когда константа используется для хранения конфиденциальной информации, необходимо создать роль Чтение<ИмяКонстанты> (англ. Read<ConstantName>). При этом, если значение должно быть доступно только администратору, создавать отдельную роль на чтение не требуется.
Например, для константы ПараметрыАдминистрированияИБ создавать отдельную роль на чтение не требуется – достаточно включения прав на чтение и просмотр в роль АдминистраторСистемы.
6. Подсистемы, отображаемые в главном командном интерфейсе
6.1. Для каждой подсистемы верхнего уровня должна быть создана роль Подсистема<ИмяПодсистемы> (англ. Subsystem<SubsystemName>), дающая право на просмотр
6.2. Если интерфейс подсистемы организован так, что часть настроек и справочников отображаются в отдельной форме, то роль, дающая право на подсистему, должна включать права на просмотр этой формы (например, в УП(ERP) часть справочников в разделах командного интерфейса не вынесены и отображаются в форме, вызываемой командой «Настройки и справочники»).
7. Отчеты
7.1. Если отчет строится на основе данных, входящих в одну элементарную функцию (п. 2.1), то в общем случае права на доступ к такому отчету можно включить в роли, созданные по этой элементарной функции.
Пример:
Отчет по исполнению заказов клиентов полностью строится на основе данных регистр накопления ЗаказыКлиентов, поэтому права на отчет нужно включить в роль, дающую право на чтение регистра.
7.2. Если на внедрении могут возникнуть задачи отдельной настройки прав к отчету, который строится на основе данных, входящих в одну элементарную функцию, то для доступа к такому отчету необходимо создать отдельную роль ПросмотрОтчета<ИмяОтчета> (англ. ViewReport<ReportName>), дающую права использования и просмотра.
Пример:
Хотя отчет по контактной информации отображает данные входящие в элементарную функцию информации о клиентах, но на внедрении может потребоваться ограничить доступ к отчету, который позволяет вывести информацию по всем клиентам сразу.
7.3. Если отчет строится на основе данных, входящих в несколько элементарных функций, необходимо создать роль ПросмотрОтчета<ИмяОтчета>, дающую права использования и просмотра.
Пример:
Отчет по выполнению плана продаж строится на основе данных о планах и данных о продажах. Права чтение этих данных дают роли, относящиеся к разным элементарным функциям. Для реализации доступа к отчету нужно создать отдельную роль.
7.4. Однотипные отчеты при проектировании прав доступа можно объединить в элементарные функции при соблюдении следующих условий:
8. Обработки и общие формы
8.1. Для каждой обработки, представляющей из себя рабочее место, т.е. в ГКИ есть отдельная команда для открытия этой обработки, должна быть создана роль ИспользованиеОбработки<ИмяОбработки> (англ. UseDataProcessor<DataProcessorName>), дающая права на просмотр и использование.
При этом не допускается объединять права доступа к разным обработкам-рабочим местам в одной роли.
8.2. Права ко всем другим типам обработок, например
должны быть назначены в роли БазовыеПрава<ИмяБиблиотеки>.
8.3. Права к обработкам, предназначенным исключительно для администратора программы, нужно назначать только роли ПолныеПрава (или АдминистраторСистемы, если предусмотрена работа только в сеансе без установленного разделителя), не создавая отдельных ролей для таких обработок.
8.4. Все эти правила равным образом применяются для общих форм. Название роли для общей формы, описанной в п. 8.1. – ИспользованиеОбщейФормы<ИмяОбщейФормы> (англ. UseCommonForm<CommonFormName>).
8.5 Исключения из этих правил описаны в п. 6.2
Пример:
В УТ 11 права к обработкам ПодборТоваров и ПоискОбъектовПоШтрихкоду назначены роли БазовыеПраваУТ.
9. Команды
9.1. Если команда не предполагает изменение данных, то в общем случае право на просмотр должно быть назначено той роли, которая дает право на просмотр объекта.
9.2. Если команда связана с изменением данных, то право на просмотр нужно назначить роли, которая дает права на изменение объектов.
10. Права, не связанные с доступом к объектам
10.1. В случае если возникает необходимость давать пользователям какие-то дополнительные права, не связанные с доступом к объектам, нужно создавать роль <НаименованиеПрава>, не дающую доступ ни к одному объекту. При этом в наименовании не нужно использовать слово «Право».
Пример:
Правильно ОтклонениеОтУсловийЗакупок
Неправильно ПравоСозданияВыпускПродукцииБезЗаказа
10.2. В коде конфигурации нужно проверять наличие у пользователя этой роли. Пользователь с ролью ПолныеПрава должен проходить проверку без необходимости включения в его профиль этой роли. Для проверки следует использовать функцию БСП Пользователи.РолиДоступны.
10.3. Использование других механизмов, кроме проверки наличия роли (или какого-то права) при реализации дополнительных прав пользователя, не допускается.
11. Права для внешних пользователей
Роли, предназначенные исключительно для предоставления прав доступа внешним пользователям (представленным в программе одним из объектов, например, элементами справочников Сотрудники, Партнеры, Физические лица и др.), следует называть с определенным префиксом.
Например, префикс Самообслуживание для доступа к рабочему месту по самообслуживанию клиентов в торговом решении:
12. Права к устаревшим объектам
Устаревшие объекты метаданных с префиксом Удалить должны быть исключены из всех ролей, кроме ролей ПолныеПрава или АдминистраторСистемы.