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

Механізм функціональних опцій- це один із інструментів розробки. Він дозволяє визначити у конфігурації ту функціональність, яка можна використовувати чи використовуватися під час впровадження залежно від потреб конкретної организации.

Робота механізму ґрунтується на двох об'єктах конфігурації:

• Функціональна опція
  З функціональними опціями, доданими до прикладного рішення, можна зв'язати об'єкти конфігурації та їх реквізити. Наприклад, з функціональною опцією Облік за складамиможна пов'язати реквізит Складдокумента Надходження товару. Тоді, якщо в режимі 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С "Параметри функціональних опцій".

[згорнути]

Це можна зробити у вікні конфігурації, додавши новий об'єкт.

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

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

УВАГА!Не можна використовувати той самий об'єкт метаданих у кількох параметрах функціональних опцій.