1с 8.3 подсистема функциональные опции. Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS. Система компоновки данных

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

Работа механизма основана на двух объектах конфигурации:

• Функциональная опция
  C функциональными опциями, добавленными в прикладное решение, можно связать объекты конфигурации и их реквизиты. Например, с функциональной опцией Учет по складам можно связать реквизит Склад документа Поступление товара . Тогда, если в режиме 1С:Предприятие включить эту функциональную опцию, поле Склад будет отображаться во всех формах документа. Если выключить - поле Склад отображаться не будет. Подробнее...

• Параметр функциональной опции
  Функциональные опции могут использоваться с параметрами. Например, для того, чтобы вид конкретной формы мог зависеть от значения параметра, выбранного в форме. Например, параметром функциональной опции Валютный учет может быть Организация . Тогда, в зависимости от того, какая организация выбрана в форме, поле Валюта взаиморасчетов будет скрыто или будет отображаться. Подробнее...

Функциональные опции - это объект метаданных, расположенный в группе "Общие":

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

Рассмотрим на примере:

Создадим функциональную опцию "УчетПоСкладам ".
Хранение: указывается поле хранящее значение.
Можно выбирать константу, реквизит справочника или ресурс регистра сведений.
Мы с вами будем использовать константу.

Создадим константу "ВестиУчетПоСкладам " и выберем ее в поле хранение. Данная константа будет отвечать за включение и отключение функциональной опции. Установим галочку "Привилегированный режим при получении". Данная галочка означает, что значения функциональной опции будут получены в привилегированном режиме:

Обновляемся, запускаем 1С Предприятие. Установим значение константы = Истина:

В результате имеем:

При установке константы = Ложь, получим:

У вас есть вопрос, нужна помощь консультанта?

Итак, мы с вами создали функциональную опцию, которая управляет полями имеющих тип СправочникСсылка.Склад

Давайте теперь рассмотрим пример использования параметров функциональных опций.
Добавим новую функциональную опцию "Валютный учет "
Хранение: Справочник.Организация.Реквизит.ВалютныйУчет

Добавим в состав реквизит документа "Установка цен номенклатуры"- "Валюта"

В форме Документа в процедурах "ПриСозданииНаСервере" и " ОрганизацияПриИзменении"
Добавим следующий код:

Обновляем конфигурацию и запускаем ее.
Создаем две Организации и для одной из них установим галочку "Валютный учет"

Что же мы получаем в итоге? В результате использования параметров функциональной опции мы с вами получили параметрическое управление полем "Валюта" в документе "Установка цен номенклатуры". Т.е. для организации "Альфа" будет отображаться поле "Валюта", а для организации "Бета" - поле "Валюта" отображаться не будет.
Давайте в этом убедимся. Открываем документ и попытаемся изменить поле "Организация"
При установке Организации = "Альфа", валюта отображается; меняем на "Бета" - валюта убирается

1. Права доступа.

На самом деле все очень просто. В 1С по умолчанию запрещено всё, что не разрешено . Есть только одна сущность, отвечающая за доступ пользователя к какой-либо функциональности или данным. Эта сущность называется "Право доступа" . Она является единственным элементом, отвечающим за доступ к конкретному режиму работы, справочнику, реквизиту....

Количество видов прав доступа предопределено платформой. Всего платформе есть две основные группы прав доступа. Общие для всей системы права доступа к механизмам платформы , отвечающие за доступ к определенным режимам работы платформы (Администрирование, Монопольный режим, Тонкий клиент,Интерактивное открытие внешних отчетов....). И объектные права доступа , позволяющие работать с различными объектами конфигурации. Их количество зависит от типа объекта конфигурации. Например, у справочника есть 16 различных видов доступа (Чтение, Добавление, Изменение, Удаление....). Для регистра сведений видов доступа всего пять. Все эти права можно установить только на уровне справочника целиком. Также можно ограничить доступ на уровне реквизитов. Но в этом случае доступна лишь часть видов прав (для справочников это права Просмотр и Редактирование).

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

Рассмотрим права доступа к справочнику. На данной схеме видно, что большинство прав является уточнением более общих прав. Если Право1 полностью расположено на схеме внутри прямоугольника другого Права2, то Право1 не может быть выдано без выдачи Права2. Самым общим правом является право "Чтение". Если право "Чтение" отсутствует, то недоступны и все остальные права. Если недоступно право "Добавление", то нельзя установить право "Интерактивное добавление". Однако, систему прав нельзя назвать полноценной иерархией. Например, право "Редактирование" можно дать лишь при наличии прав "Просмотр" и "Изменение". Но можно дать "Просмотр" без "Изменение" или "Изменение" без "Просмотр".

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

2. Роли - механизм предоставления прав доступа

Рассмотрим, как именно выполняется предоставление пользователю прав доступа. Для удобства выдачи прав доступа в платформе 1С используется специальный механизм "Роли" . Он является прослойкой между пользователями информационной базы и правами доступа. В каждой роли объединен набор прав доступа, назначение которых имеет смысл выполнять только одновременно. Например, в роли "Чтение контактной информации" логично объединить наборы прав, отвечающих за связанные справочники с контактной информацией. Наиболее простым способом установки роли пользователю является открытие карточки пользователя ИБ в конфигураторе и установка галочек напротив нужных пользователю ролей . Это универсальный способ и он работает в любых конфигурациях. Однако, с усложнением конфигураций и увеличением количества ролей он стал довольно трудоемкий. Поэтому в актуальных типовых решениях есть дополнительная прослойка между пользователем ИБ и ролями. Эта прослойка реализована в виде подсистемы "Управления доступом" . Она позволяет объединять роли в более крупные сущности - "Профили" и назначать пользователю уже не отдельные роли, а профили, содержащие наборы из нескольких ролей.

Рассмотрим схему назначения пользователям прав доступа, используемую в большинстве типовых конфигураций. В упрощенном виде ее можно представить следующим образом. Вводятся новые сущности "Профиль доступа" и "Группа доступа" . В каждый профиль доступа включается несколько ролей. И каждому пользователю назначается одна или несколько групп доступа. Далее каждая группа доступа связывается с профилем доступа. В итоге мы получаем возможность указывать для пользователя не просто роли, а комплекты ролей в зависимости от выполняемых им функций.

С технической точки зрения данная система выдачи прав реализовывается с участием двух стандартных подсистем. Подсистема "Управление доступом" используется для настройки связи групп доступа с предопределенными в конфигурации ролями. Подсистема "Пользователи" используется для настройки связей пользователей ИБ с группами доступа конфигурации.

3. "Логика разрешений" как правило пересечения ролей.

Важно понимать, что в 1С общая логика управления доступом это логика разрешений . В платформе 1С вообще нет никаких механизмов запрета доступа . Есть только механизмы выдачи доступа . По умолчанию доступ ко всем данным запрещен, и настройка доступа заключается в выдаче каждому пользователю нужных ему прав . Это означает, что если какой-то ролью пользователю дано право на просмотр документов "Реализация товаров", то никакими способами нельзя это право отнять другими ролями или любыми другими механизмами платформы и конфигурации. Можно изначально выдать не полный доступ к справочнику, а отфильтровать с помощью RLS данные, на которые мы даем доступ. Но если доступ уже выдан, то забрать его другими ролями уже нельзя.

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

В платформе есть возможность дать пользователю дополнительные права на время выполнения отдельной операции. Эта возможность называется "Привилегированный режим". Он позволяет пользователю выполнять действия над данными, которые ему не доступны. Однако, в платформе нет возможности даже временно уменьшить имеющиеся у пользователя права.

4. Косвенное управление доступом.

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

4.1. Функциональные опции.

К системе управления доступом иногда относят механизм функциональных опций . Это не совсем верно, так как функциональные опции никак не влияют на доступ к данным. Это исключительно интерфейсный механизм, предназначенный для упрощения интерфейса для пользователя. Он появился в платформе 8.2 как результат усложнения функционала конфигураций. Функциональные опции предназначены для скрытия из интерфейса функционала, не используемого в данной конкретной компании или данным конкретным пользователем. Механизм влияет только на отображение данных. Из интерфейса исчезают команды, а на формах скрываются реквизиты, отключенные функциональными опциями. При этом у пользователя остается доступ ко всем этим командам и реквизитам . Он может без каких-либо проблем работать со скрытыми данными программно при помощи обработок.

Подробнее о работе с функциональными опциями можно почитать на ИТС

4.2. RLS (Record Level Security)

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

Для настройки такого разрешения есть дополнительный механизм RLS (Record Level Security) . Как и следует из названия, этот механизм контроля доступа на уровне конкретных записей таблиц. Если права доступа дают доступ к таблицам вцелом (справочникам) или колонкам таблиц (реквизитам), то RLS определяет конкретные строки таблиц (записи), с которыми разрешено работать пользователю. Он позволяет определить данные, которые пользователю доступны.

При разборе данного механизма стоит всегда помнить, что RLS не является механизмом запрета доступа . Он является механизмом фильтрации выдачи доступа . Т.е. RLS не влияет на имеющиеся у пользователя права, он является фильтром, ограничивающим выдачу прав. RLS влияет только на ту конкретную связь "Роль" - "Право доступа", в которой он прописан. И не влияет на права доступа, выданные с помощью других ролей. Например, если одной ролью будет разрешен доступ к документам только по Организации1, а другой ролью доступ к документам по Складу1, то в итоге пользователь получит доступ ко всем документам, в которых указана Организация1 ИЛИ Склад1. Поэтому если пользователю выдается несколько ролей, то фильтр с помощью RLS нужно ставить в каждой роли по обоим полям (по организации и складу). В типовых решениях эта задача обычна решается созданием одной роли, в которой прописываются все возможные фильтры RLS. Данная роль потом назначается всем пользователям, работающим с данными справочниками. Также контролируется, чтобы у пользователя не были доступны другие роли, содержащие право доступа к ограниченным документам.

Так же стоит обратить внимание что фильтры RLS можно наложить не на все возможные виды доступа к данным, а лишь на виды доступа верхнего уровня . Например, для справочников из имеющихся шестнадцати видов доступа фильтры RLS можно наложить лишь на четыре основных: Чтение, Изменение, Добавление и Удаление. Это означает, что мы не можем, например, дать пользователю одновременно право "Изменение" без фильтра для возможности работать программно с любыми документами и право "Редактирование" с фильтром RLS по организации для интерактивной работы. Если нам нужно, чтобы пользователь мог редактировать документы с фильтром RLS , мы обязаны наложить общий фильтр на верхнем уровне "Изменение" или "Чтение".

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

4.3. Разделение данных.

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

В каком-то общем смысле этот механизм можно считать тоже фильтром на данные и частным случаем реализации RLS. В отличии от RLS разделение гораздо более жесткий механизм. И благодаря этой жесткости у разработчиков есть техническая возможности дополнительными индексами сделать такую фильтрацию без свойственных RLS замедлений работы.

Фактически RLS это просто дополнительные отборы , добавляемые автоматически к каждому запросу к базе данных. Разделение данных это добавление разделителя во все разделенные таблицы и их индексы, в том числе в кластерный. Данные группируются в разрезе разделителя, т.е. физически перераспределяются по диску в отдельные группы по каждому значению разделителя. Благодаря этому каждый пользователь работает только со своими данными, и серверу не нужно при каждом запросе физически просматривать всю таблицу. Достаточно просмотреть только область данных текущего раздела.

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

4.4. Программный код.

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

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

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

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

4.5. Сравнение вариантов.

Попробуем кратко сравнить рассмотренные варианты дополнительного ограничения данных.

5. Итоги.

У каждого способа настройки ограничений свои плюсы и минуса. С точки зрения технологии наиболее правильный способ это грамотное разбиение на роли. Для фильтрации доступных данных надежнее всего использование RLS. Именно для этой задачи механизм предназначен. Точечные ограничения проще всего выполнять с помощью программного кода. Функциональные опции и разделение данных достаточно специфичные механизмы, не предназначенные для ограничения доступа. Хоть в некоторых случаях и могут для этого использоваться.

Практически все типовые решения на платформе 1С:Предприятие 8.x используют механизм функциональных опций. Он позволяет управлять функциональностью конфигурации блочно.

Так, например, опция "Использование внутренних заказов" (см. скриншот справа) позволяет сделать доступным этот документ для использования в режиме "1С:Предприятие" пользователю, а также включает отдельные ветки алгоритмов, связанных с данным функционалом.

Сегодня в статье мы рассмотрим работу функциональных опций, их настройку и небольшой пример их использования на тестовой конфигурации. Начнем с рассмотрения принципа их работы.

Принцип работы

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

В ветке конфигурации "Общие->Функциональные опции" мы можем создать новый объект или посмотреть свойства уже созданных опций. В тестовой конфигурации создадим функциональную опцию "ВключитьВажность". В самом начале, когда еще не была произведена настройка объекта, окно списка его свойств будет выглядеть следующим образом:

Свойства "Имя" и "Синоним" имеют стандартное назначение. Особый интерес вызывают настройки "Хранение" и "Состав".

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

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

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

Опция "Привилегированный режим при получении" позволяет отключить проверку прав доступа при получении значения функциональной опции, что позволит положительно повлиять на производительность (будут исключены излишние операции проверки прав доступа) и снизит сложность дальнейшей разработки (не нужно настраивать права для объекта, хранящего значение функциональной опции).

Пример использования

В нашей тестовой конфигурации создадим перечисление "Важность", а также константу

"ВключитьВажность". Созданные объекты представлены на следующем скриншоте.

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

• "Комментарий" с типом "Строка".
• "Важность" с типом "ПеречислениеСсылка.Важность".

В состав функциональной опции добавим реквизит документа "Важность" и далее рассмотрим поведение платформы в пользовательском режиме.

Запустив программу в режиме "1С:Предприятие" откроем тестовый документ. На форме мы не увидим реквизита "Важность", поскольку еще не включили функциональную опцию.

Чтобы включить использование реквизита "Важность" необходимо установить значение константы "ВключитьВажность" в ИСТИНА. Тогда форма изменится следующим образом:

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

Рассмотрим несколько интересных моментов работы данного объекта конфигурации:

1. Настройка функциональных опций практически никак не влияет на SQL-запросы, формируемых платформой.

Например, при открытии документа с отключенной функциональной опцией, платформа в любом случае в запросе получает значение этого реквизита. На следующем скриншоте приведены SQL-запросы, формируемых с включенной и отключенной опцией.

2. Элемент формы "Важность" на форме, вне зависимости от значения функциональной опции, всегда имеет значения для свойств "Видимость" и "Доступность" равными ИСТИНА.

Действительно, как при создании формы на сервере, так и при открытии формы, а также при дальнейшей работе с ней, свойства "Видимость" и "Доступность" не устанавливаются в ЛОЖЬ платформой автоматически. Вероятно, 1С:Предприятие 8.x делает это "за кулисами".

3. Платформа для получения значения функциональной опции формирует SQL-запрос к СУБД в соответствии с объектом хранения, т.е. к константе. В одной из предыдущих статей мы уже говорили о построении SQL-запросов к константам и способе их хранения в базе данных.

В нашем примере платформа формирует следующий SQL-запрос:

Что касается момента получения значения функциональной опции, то платформа руководствуется следующим принципом: первое получение значения функциональной опции происходит при обращению к объекту/реквизиту, входящим в ее состав. В дальнейшем платформа использует кэшируемое значение до тех пор, пока не будет изменено значение объекта, который хранит это значение (в нашем примере - константы "ВключитьВажность") или перезапущен сеанс пользователя. Значение функциональной опции кэшируется в рамках отдельного сеанса.

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

Вывод

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

За опыт работы с платформой очень редко приходится использовать функциональные опции, поскольку заказчик точно знает, что ему необходимо. И создавать какие-то универсальные механизмы, за которые придется дополнительно доплачивать, плюс не факт, что они будут использоваться, является очень редким при доработке типовых решений или внедрении на конкретном предприятии.

Файлы для загрузки:

Объект 1с "Функциональные опции" - предназначены для выделения в прикладном решении функциональности, которую можно включать (выключать) при внедрении, не изменяя само (совместно с Подсистемами формируют интерфейс тонкого клиента 1С). Являются частью механизма функциональных опций.

Механизм функциональных опций включает в себя два объектов метаданных:

1. Функциональная опция;
2. Параметры функциональных опций.

Подробнее

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

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

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

Можно сказать, что параметры функциональных опций являются осями координат пространства значений функциональных опций. Причем один параметр функциональных опций может определять значение «своей» оси координат одновременно для множества функциональных опций.

[свернуть]

Функциональные опции могут оказывать влияние:

1. на пользовательский интерфейс:
   • глобальный ;
   • реквизиты (в том числе колонки реквизита формы типа ТаблицаЗначений или ДеревоЗначений );
   • команды формы;
2. на отчеты, реализованные с помощью системы компоновки данных;
3. на алгоритмы, написанные на встроенном языке – имеется возможность получать значения функциональных опций из встроенного языка и использовать их в различных условиях, например, для уменьшения объема вычислений (см., например, ).

ВНИМАНИЕ! Если клиентское приложение работает с файловым вариантом информационной базы через веб-сервер, то изменение функциональной опции приведет к изменению пользовательского интерфейса только после перезапуска веб-сервера (перезапуск клиентского приложения не вызовет изменение пользовательского интерфейса).

Свойства Функциональных опций 1С

• Хранение - поле, в котором необходимо выбирать объект с типом булево. Как правило, используются константы.
• при получении - флаг отвечает за возможность получения значения функциональной опции в привилегированном режиме.
• Состав - список объектов и реквизитов объектов, видимость которых включается/выключается при выключении/выключении функциональной опции (будет управляться с помощью управляемой формы).

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

Особенности использования Функциональных опций 1С:

1. Функциональные опции могут иметь значения произвольного типа (не обязательно Булево ).
2. Добавляя новую константу для использования функциональной опции, не забудьте включить ее в соответствующую подсистему и назначить на нее права.
3. Работа с функциональными опциями доступна из встроенного языка, благодаря чему разработчик может создавать собственные алгоритмы значений функциональных опций.
4. Команда командного интерфейса будет исключена из командного интерфейса в случае, если функциональной опцией отключен:
   • реквизит, являющийся параметром команды;
   • тип параметра команды (если тип параметра команды составной, то команда становится недоступной тогда, когда отключаются все типы параметра).

ВНИМАНИЕ! Функциональные опции и их параметры не влияют на состав базы данных: все таблицы и поля присутствуют в БД независимо от состояния функциональных опций.

Влияние функциональных опций на реквизиты и команды формы:

1. управляемой формы типа <Вид>Объект (СправочникОбъект , ДокументОбъект и т. д.) будет отключен в том случае, если функциональной опцией отключен соответствующий объект . Анализируются только те функциональные опции, которые не имеют параметров.
2. Основной реквизит управляемой формы типа ДинамическийСписок будет отключен в том случае, если функциональной опцией отключен объект конфигурации, который указан в качестве основной таблицы динамического списка. Анализируются только те функциональные опции, которые не имеют параметров.
3. Отключается реквизит формы ссылочного типа, если объект конфигурации, образующий этот тип, отключен функциональной опцией. Реквизит формы составного типа отключается в том случае, если функциональные опции отключают все составляющие типы.
4. Таблица формы будет отключена, если она отображает данные реквизита формы, отключенного функциональной опцией.
5. В диалоге выбора типов (например, для полей ввода, связанных с реквизитами составного типа) отсутствуют типы, если объекты конфигурации, формирующие эти типы, отключены функциональной опцией. Информация о типах, отключенных функциональными опциями, кешируется на стороне клиента и очищается через 20 минут или во время вызова метода ОбновитьИнтерфейс() .

ВНИМАНИЕ! В отличие от командного интерфейса, значения параметров функциональных опций устанавливаются только для конкретного экземпляра формы.

Создание параметра функциональных опций

Параметр функциональной опции создается с помощью объекта конфигурации 1С "Параметры функциональных опций".

[свернуть]

Это можно сделать в окне конфигурации, добавив новый объект.

Свойства параметра функциональных опций:

• Использование - устанавливает набор объектов, значения которых будут определять то, как следует выбирать значение функциональной опции. В список доступных объектов входят справочники и измерения регистра сведений. Для каждого параметра функциональных опций в данном списке можно выбрать один справочник (из всего перечня справочников) и по одному измерению каждого регистра сведений.

ВНИМАНИЕ! Нельзя использовать один и тот же объект метаданных в нескольких параметрах функциональных опций.