Контрол на достъпа: роли, права, профили, групи за достъп, функционални опции, RLS. Изграждане на разпределени информационни системи, търсене, рутинни задачи, функционални опции 1c функционална опция не е намерена

Функционални опции– това е една от новите функции на платформата 1C:Enterprise 8.2. Смисълът на използването им е, че ви позволяват да персонализирате потребителския интерфейс в съответствие с настройките на функционалните опции и да зададете видимостта на детайлите във формулярите. В допълнение, разработчикът има възможност да внедри програмен код, чието изпълнение зависи от състоянието на функционалната опция.

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

Нека създадем нова константа и я извикаме Счетоводство на заплатите, Тип - Булева стойност. Нека включим константата в подсистемата Администрацияи в постоянна форма, за да можем да го редактираме. В допълнение, под формата на константи, ще зададем манипулатора AfterWrite, както следва:

&На клиентската процедура AfterRecord(RecordParameters) UpdateInterface(); Край на процедурата

Значението на използването на командата UpdateInterface()е да актуализирате и преначертаете интерфейса, след като промяната в константата, свързана с функционалната опция, влезе в сила. В противен случай ще трябва да рестартирате конфигурацията, за да влязат в сила промените.

Нека създадем нова функционална опция и я извикаме Счетоводство на заплатите, на отметката Основен, в параметъра СъхранениеНека посочим току-що създадената константа, фиг. 7.23. Нека включим функционална опция в подсистемата Администрация.

Ориз. 7.23.

Сега нека отидем в раздела на прозореца за настройки на функционалните опции Съединениеи изберете всичко (фиг. 7.24), което се отнася до изчисляването на заплатите. Ако някакви обекти, например директории, принадлежат към различни части на конфигурацията, ние няма да ги маркираме, в противен случай, когато функционалната опция е изключена, те ще „изчезнат“ от интерфейса.

Избор на подсистема Изготвяне на заплатив този случай не води до автоматичен избор на всички обекти, включени в подсистемата. Когато избираме, имаме предвид само скриване или показване на част от командния интерфейс Изготвяне на заплати.

Като стартираме системата в потребителски режим, можем да активираме или деактивираме видимостта на обекти, свързани с подсистемата за заплати на нашата конфигурация, просто като зададем или премахнем отметката от флага на константата Счетоводство на заплатите.

По-трудно случай на употребафункционални опции се състои от задаване на видимостта на отделните елементи на формуляра, ако стойността на функционалната опция се съхранява в атрибута на обект.

Нека направим промени в конфигурацията, по-специално в директорията Физически лицадобавете атрибут на логически тип Има опит в услугите за персонали го поставете във формуляра на елемента директория.

Механизъм за функционални опциие един от инструментите за развитие. Тя ви позволява да дефинирате в конфигурацията функционалността, която може или не може да се използва по време на внедряването, в зависимост от нуждите на конкретна организация.

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

• Функционална опция
  Конфигурационните обекти и техните детайли могат да бъдат свързани с функционални опции, добавени към приложно решение. Например с функционалната опция Складово счетоводствоможете да свържете подпорите Наличностдокумент Получаване на стоки. След това, ако активирате тази функционална опция в режим 1C:Enterprise, полето Наличностще се показва във всички формуляри на документи. Ако го изключите - поле Наличностняма да се покаже. Прочетете още...

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

1. Права за достъп.

Всъщност всичко е много просто. В 1C по подразбиране всичко, което не е позволено, е забранено. Яжте само един субект, отговорен за достъпапотребител до всяка функционалност или данни. Това образувание се нарича „Право на достъп“. Тя се случва да бъде единственияелемент, отговарящ за достъпа до определен режим на работа, директория, детайли....

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

Всички права за достъп са взаимосвързани и зависими едно от друго. Има права на по-високо и по-ниско ниво. Не можете да предоставите право от по-ниско ниво, ако потребителят няма право да извърши действие от по-високо ниво.

Нека помислим права за достъп до директорията.Тази диаграма показва, че повечето права са разяснения на по-общи права. Ако Right1 е напълно разположен на диаграмата вътре в правоъгълника на друг Right2, тогава Right1 не може да бъде издаден без издаване на Right2. Най-често срещаното право е правото „Четене“. Ако правото за четене не е налично, тогава всички други права не са налични. Ако правото „Добавяне“ не е налично, тогава правото „Интерактивно добавяне“ не може да бъде зададено. Въпреки това, системата от права не може да се нарече пълноценна йерархия.Например правото „Редактиране“ може да бъде дадено само ако имате права „Преглед“ и „Редактиране“. Но можете да дадете „Преглед“ без „Промяна“ или „Промяна“ без „Преглед“.

Правото на достъп е минималната единица за достъп. Целият контрол на достъпа се свежда до предоставяне на потребителя на необходимия набор от права.Останалите обекти (роли, групи за достъп) са просто допълнителни обвързвания, които служат за групиране и по-удобно издаване на права за достъп.

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

Нека да видим как точно се прави предоставяне на права за достъп на потребителя.За удобство при издаване на права за достъп в платформата 1C, специален Механизъм "Роли".. Това е слой между потребителите на информационната база и правата за достъп. Всяка роля съчетава набор от права за достъп, чието присвояване има смисъл само едновременно. Например, в ролята „Четене на информация за контакт“ е логично да комбинирате набори от права, отговорни за свързани директории с информация за контакт. Най-лесният начин да зададете роля за потребител е отваряне на потребителската карта за информационна сигурност в конфигуратора и поставяне на отметки в квадратчетата до ролите, от които се нуждае потребителят. Това е универсален метод и работи във всяка конфигурация. Въпреки това, с нарастващата сложност на конфигурациите и увеличаването на броя на ролите, това стана доста трудоемко. Следователно в настоящите стандартни решения има допълнителен слой между потребителя за информационна сигурност и ролите. Този слой е внедрен във формата Подсистема "Контрол на достъпа".. Тя ви позволява да комбинирате роли в по-големи обекти - „Профили“ и да присвоявате на потребителя не отделни роли, а профили, съдържащи набори от няколко роли.

Нека разгледаме схемата за предоставяне на права за достъп на потребителите, използвана в повечето типични конфигурации. В опростена форма тя може да бъде представена по следния начин. Въвеждат се нови субекти „Профил за достъп“И "Група за достъп". Всеки профил за достъп включва няколко роли. И на всеки потребител се присвояват една или повече групи за достъп. След това всяка група за достъп се свързва с профил за достъп. В резултат на това получаваме възможността да зададем не само роли за потребителя, но набори от роли в зависимост от функциите, които изпълнява.

От техническа гледна точка тази система за издаване на права се реализира с участието на две стандартни подсистеми. Подсистемата "Контрол на достъпа" се използва за конфигуриране на връзката на групи за достъп с предварително дефинирани роли в конфигурацията. Подсистемата "Потребители" се използва за конфигуриране на връзки между потребители за информационна сигурност и групи за достъп до конфигурация.

3. “Разрешителна логика” като правило за пресичане на ролите.

Важно е да се разбере, че в 1C е общата логика за контрол на достъпа логика на разрешението. В платформата 1C като цяло няма механизми за отказ на достъп. Има само механизми издаване на достъп. По подразбиране достъпът до всички данни е отказан и настройването на достъпа се състои в предоставяне на всеки потребител на правата, от които се нуждае. Това означава, че ако някаква роля дава на потребителя право да преглежда документи „Продажби на стоки“, тогава това право не може да бъде отнето по никакъв начиндруги роли или друга платформа и механизми за конфигуриране. Първоначално можете да не давате пълен достъп до директорията, а да филтрирате данните, до които даваме достъп, като използвате RLS. Но ако достъпът вече е предоставен, той вече не може да бъде върнат от други роли.

Ето защо, когато ограничавате потребителския достъп до директория чрез роли, е много важно да проверите дали на потребителя не е присвоена друга роля в същата директория. В противен случай първата роля ще даде необходимия достъп, който втората не може да откаже.

Платформата има възможност да предоставя на потребителя допълнителни права, докато извършва отделна операция. Тази функция се нарича Привилегирован режим. Позволява на потребителя да извършва действия с данни, които не са му достъпни. Платформата обаче няма възможност дори временно да намали правата на потребителя.

4. Индиректен контрол на достъпа.

Съществуват отделни механизми, които, макар и да не са пряко предназначени за контрол на достъпа, му влияят индиректно и могат да се използват за допълнителни ограничения. Нека да разгледаме основните им характеристики.

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

Системата за контрол на достъпа понякога се нарича механизъм функционални опции. Това не е съвсем вярно, тъй като функционалните опции не влияят по никакъв начин на достъпа до данни. Това е чисто интерфейсен механизъм,предназначен да опрости интерфейса за потребителя. Появи се в платформа 8.2 в резултат на по-сложна функционалност за конфигурация. Предвидени са функционални опции за скриване от интерфейсафункционалност, която не се използва от тази конкретна компания или от този конкретен потребител. Механизмът засяга само показването на данни. Командите изчезват от интерфейса и детайлите, деактивирани от функционални опции, са скрити във формулярите. При което потребителят все още има достъп до всички тези команди и подробности. Може да работи със скрити данни програмно, като използва обработка без никакви проблеми.

Можете да прочетете повече за работата с функционални опции на ITS

4.2. RLS (сигурност на ниво на запис)

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

Има допълнителен механизъм за конфигуриране на тази резолюция RLS (сигурност на ниво на запис). Както подсказва името, този механизъм за контрол на достъпа е на ниво специфични записи в таблица. Ако правата за достъп предоставят достъп до таблици като цяло (директории) или колони на таблици (подробности), тогава RLS определя конкретни редове от таблици (записи), с които потребителят има право да работи. Тя ви позволява да определите данните, които са достъпни за потребителя.

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

Също така си струва да се отбележи, че RLS филтрите не могат да се прилагат към всички възможни видове достъп до данни, а само към видове достъп от най-високо ниво. Например, за директории, от шестнадесетте налични вида достъп, RLS филтрите могат да бъдат приложени само към четири основни: четене, модифициране, добавяне и изтриване. Това означава, че не можем например да дадем на потребителя едновременно право „Редактиране“ без филтър за възможността да работи програмно с всякакви документи и право „Редактиране“ с RLS филтър по организация за интерактивна работа. Ако имаме нужда потребителят да може да редактира документи с RLS филтър, от нас се изисква да наложим общ филтър на най-високото ниво на „Редактиране“ или „Четене“.

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

4.3. Разделяне на данните.

Друг механизъм, който засяга достъпа до данни, е разделяне на данните. Този механизъм е предназначен да поддържа няколко независими бази данни в една физическа база данни, които имат обща конфигурация и общи директории. В някои много ограничени случаи този механизъм може да се счита за контрол на достъпа. Когато е разрешено, всеки потребител може да работи само в една от своите независими бази данни, но да използва общи данни.

В някакъв общ смисъл този механизъм може също да се счита за филтър за данни и специален случай на внедряването на RLS. За разлика от RLS, разделянето е много по-твърд механизъм. И благодарение на тази твърдост разработчиците имат техническата възможност да използват допълнителни индекси за извършване на такова филтриране без присъщите забавяния на RLS.

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

Въпреки това, точно поради това физическо преразпределение на данни, когато работите като пълен потребител, който няма филтър, базиран на стойности на разделители, всички заявки се изпълняват много, много бавно. Без стойността на разделителя е невъзможно пълното използване на индексите, така че количеството данни, физически прочетени от диска и обработени с всяка заявка, може нарастват с порядъци. Съответно, в действителност разделянето има смисъл само ако всички потребители, които постоянно работят в базата данни, ще работят само в рамките на собствената си област.

4.4. Програмен код.

Може би най-универсалният начин за задаване на допълнителни ограничения е програмен код. Те могат да повлияят на всякакви платформени механизми. Например, за да ограничи достъпа до документи, разработчикът може да добави филтър към формуляра за списък с документи, към формуляра за избор и може програмно да провери възможността за преглед на данни от документа при отваряне на конкретен формуляр на документ. Разработчикът може да приложи филтър в отчетите си, когато избира данни.

Въпреки това програмният код няма начин да се ограничат правата като цяло чрез конфигурация. Най-много, което един разработчик може да направи, е да вгради ограничения в конкретни индивидуални механизми за извличане на данни. Поради факта, че 1C използва обектен модел за работа с данни, програмният код може да гарантира защита на данните от модификация, добавяйки необходимите проверки към обектния модул. Но разработчикът не може напълно да гарантира, че потребителят определено няма да може да получи информация за документите за внедряване на други хора чрез други отчети или обработка.

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

Винаги има опции за получаване на забранени данни чрез заявка, собствена обработка или доклад. Освен ако не ограничите много строго списъка с конфигурационни функции, използвани от потребителя, и не добавите отделен филтър към всеки механизъм (формуляр, обработка, отчет, заявка), разрешен на потребителя.

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

Нека се опитаме да сравним накратко разгледаните опции за допълнително ограничаване на данните.

5. Резултати.

Всеки метод за задаване на ограничения има своите плюсове и минуси. От технологична гледна точка най-правилният начин е правилното му разделяне на роли. Най-надеждният начин за филтриране на наличните данни е използването на RLS. Именно за тази задача е проектиран механизмът. Точковите ограничения са най-лесни за прилагане с помощта на код. Функционалните опции и разделянето на данни са доста специфични механизми, които не са предназначени да ограничават достъпа. Въпреки че в някои случаи те могат да се използват за това.

Предназначение

Функционалните опции позволяват на разработчика да опише конфигурационни възможности, които могат бързо да бъдат включени или изключени на етапа на внедряване и/или по време на работа на системата. Например възможността за работа с допълнителни свойства на продукта може да бъде отделена в отделна функционална опция. Тогава, ако деактивирате тази функция, всички свързани (с допълнителни свойства на продукта) функции ще „изчезнат“ в интерфейса за конфигуриране.

Системата може автоматично да вземе предвид състоянието на направените настройки - да скрие деактивираните функции, което прави интерфейса на приложението по-ясен и разбираем за потребителя.

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

Функционалните опции могат да окажат влияние:

• към потребителския интерфейс – когато деактивирате функционални опции, системата скрива всички свързани с нея елементи в потребителския интерфейс. Засегнати са следните елементи на интерфейса:
  • глобален команден интерфейс;
  • форми;
  • отчети, реализирани с помощта на система за съставяне на данни.
• алгоритми, написани на вграден език - възможно е програмно да се получат (и зададат) стойностите на функционалните опции и да се използват в различни условия, например, за да се намали количеството на изчисленията.

Глобален команден интерфейс

Ефектът от функционалните опции върху глобалния команден интерфейс е, че системата скрива командите на всички обекти, свързани с недостъпни опции. Например, ако стойността на функционалната опция Закупуване е False, тогава командите за отваряне на секция Закупуване, създаване на документ за получаване на стоки, отваряне на списъка за получаване на стоки и т.н. ще бъдат скрити.

От своя страна опцията за закупуване може да вземе предвид стойността на параметър на функционална опция, например Организация. Чрез промяна на стойността на този параметър с помощта на вградени езикови методи можете да промените състоянието на функционалната опция и следователно видимостта на интерфейсния елемент.

Форма

В управляван формуляр функционалните опции могат да повлияят на атрибутите на формуляра, командите и (като резултат) свързаните с тях елементи на формуляр.

Видимостта на полетата и таблиците на управлявания формуляр зависи от видимостта на детайлите на формуляра, а видимостта на бутоните зависи от видимостта на командите.

Система за съставяне на данни

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

За повече информация относно влиянието на функционалните опции върху наличността на полета в отчет вижте раздела „Функционални опции и разрешение за преглед на полета в отчет“ на главата „Управлявани отчети“.

Обща схема на работа

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

Функционална опция е обект на метаданни, който пряко влияе върху състава на интерфейса на приложението. Използвайки обекти от този тип, можете да скриете елементи, които са свързани с недостъпна функционалност. Например опцията Валутно счетоводство може да премахне директорията Валута, полето Валута от документи и колоната Валутна сума от отчетите. Източникът на стойността на функционална опция е обектът на метаданни, избран като свойство Storage, например това може да е константа.

Ако стойността на функционална опция е съхранена в атрибут на директория или ресурс на информационен регистър, е необходима допълнителна информация, която показва точно как да изберете стойността на опцията. За целта е предвиден отделен обект на метаданни - Параметър на функционалните опции.

Можем да кажем, че параметрите на функционалните опции са координатните оси на стойностното пространство на функционалните опции. Освен това, един параметър на функционална опция може да определи стойността на „неговата“ координатна ос едновременно за много функционални опции.

Нека да разгледаме един пример: да кажем, че количественото отчитане зависи от единицата в организацията. В нашата информационна база данни можете да поддържате записи от името на различни организации.

За да съхраняваме стойностите на функционалните опции, ще създадем информационен регистър, където размерите (координатните оси) ще бъдат:

• Организация (от подходящ вид);
• Разделение (от съответния вид).

Ресурсът на информационния регистър ще бъде стойността на функционалната опция за количествено счетоводство.

Тогава общата структура на конфигурацията ще изглежда така:

• Регистър на информация Количествено счетоводство:
  • Организация на измеренията,
  • Dimension Division,
  • QuantitativeAccounting ресурс от тип Boolean.
• Функционални опции параметър Организация. Свойството Използване указва измерението на регистъра на организацията на информацията QuantitativeAccounting.
• функционални опции параметър Отдел. Свойството Използване указва измерението на разделението на регистъра на информацията QuantitativeAccounting.
• Функционалната опция QuantitativeAccounting, свойството Storage, сочи към ресурса QuantitativeAccounting на информационния регистър на QuantitativeAccounting.

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

Взаимодействие с други обекти

Функционалните опции могат да бъдат присвоени на следните конфигурационни обекти:

• подсистеми,
• Общи команди
• Константи,
• Критерии за подбор,
• указател,
• документ,
• списание,
• сметкоплан,
• План на видове характеристики,
• План на видовете изчисления,
• бизнес процес,
• задача,
• Планове за обмен,
• Докладвай,
• лечение,
• Регистър за натрупване,
• Регистър на информацията
• Счетоводен регистър,
• Изчислителен регистър,
• екип,
• Подробности за обект на метаданни,
• таблична част,
• Подробности за табличната част,
• Счетоводен знак
• Subconto счетоводен атрибут,
• Подробности за адресиране
• Регистрирайте измерване,
• Регистрирайте ресурс.

Функционалните опции също могат да повлияят на видимостта на елементите на формуляра.

Създаване

Създаване на опция за функция

За да създадете функционална опция, трябва да създадете конфигурационен обект Functional Option. Това може да стане в режим Конфигуратор по обичайния начин, тоест в прозореца за конфигурация изберете Общи, след това Функционални опции и добавете нов обект.

Това ще създаде конфигурационен обект за функционална опция, който може да се използва за присвояване на функционални опции на други обекти с метаданни.

В допълнение към името, обектът има задължително свойство - Storage. В редактора можете да изберете един от обектите за него, който ще бъде източник на стойността на опцията. Списъкът с налични обекти включва:

• константи,
• подробности за директорията,
• ресурси на информационния регистър.

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

Създаване на параметър за функционални опции

За да създадете параметър на функционална опция, трябва да създадете конфигурационен обект със същото име. Това може да се направи в клона Общи, елемента за настройки на функционалните опции.

В допълнение към името, параметърът има задължително свойство за използване. Той определя набор от обекти, чиито стойности ще определят как трябва да бъде избрана стойността на функционална опция. Списъкът с налични обекти включва директории и измерения на информационния регистър. За всеки параметър на функционални опции в този списък можете да изберете една директория (от целия списък с директории) и едно измерение на всеки информационен регистър.

Използване

Присвояване на метаданни на обекти

Обект с метаданни (например директория) може да бъде присвоен на една или повече функционални опции. За да направите това, използвайте свойството Функционални опции, което съдържа връзки към функционални опции, създадени в конфигурацията. Списъкът с налични опции е ограничен само до тези опции, за които на свойството Storage е присвоен обект, чийто тип стойност е Boolean.

Задаване на детайли и команди на формуляра

Обектите, принадлежащи към формуляра (Детайли и Команди), също могат да се използват в механизма за функционални опции.

Това може да стане в редактора на формуляри, като зададете свойството Функционални опции за необходимия обект.

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

Ако на атрибут или команда на формуляр не е присвоена функционална опция, тогава атрибутът или командата на формуляр се считат за винаги видими. В противен случай атрибут или команда на формуляр се считат за видими, ако поне една от присвоените му функционални опции е активирана.

Използвайте в механизъм за ограничаване на достъпа до данни

Съгласно механизма за ограничаване на достъпа до данни, функционалните опции могат да се използват по същия начин като опциите за сесии. Допустимо е да се използват само опции, независими от параметри, тоест такива, които са обвързани с константи.

Определяне на стойността на функционална опция

Стойността на функционалната опция се определя от обекта, който е указан в свойството Storage. В случай на константа се използва нейната стойност. За опция, свързана с атрибут на директория или ресурс на информационен регистър, стойностите, съхранени в тези обекти. За да се намери конкретен обект, който съхранява стойността на функционална опция, е необходима допълнителна информация - набор от стойности за параметрите на функционалните опции.

Ако дадена опция се съхранява в атрибут на директория, параметърът трябва да съдържа връзка към конкретен елемент на директория. Ако опцията се съхранява в ресурс на подробен регистър, стойностите на всички измерения на регистъра трябва да бъдат посочени. В този случай всяко измерване трябва да се характеризира със свой собствен параметър.

Вградените езикови методи ви позволяват да получите стойността на опция, както в зависимост от предадените параметри, така и за параметри, зададени за командния интерфейс или конкретна форма (за повече подробности вижте раздела „Работа с функционални опции във вградения на език” от тази глава).

Ако функционална опция е свързана с периодичен информационен регистърен ресурс, тогава системата използва част от последния, за да получи стойността на опцията. Ако искате да получите стойността на опцията за друга дата, трябва да посочите стойност за параметъра на функционалните опции Период (Период), който има тип Дата, която ще се използва като дата за получаване на отрязъка. Този параметър не е необходимо да се създава в метаданните. Предоставя се автоматично от системата.

Управление на стойностите на параметрите на функционалните опции

Стойностите на параметрите се задават с помощта на вградени езикови методи. В този случай е възможно да се ограничи обхватът на стойностите на параметрите. Параметрите могат да се задават в командния интерфейс и в конкретен екземпляр на формуляр.

Работа с функционални опции във вградения език

Методите за работа с функционални опции могат да бъдат разделени на две части:

• методи за получаване на стойността на опцията,
• методи за работа с параметри на функционални опции.

Работа със стойности на функционални опции

Глобалните контекстни методи GetFunctionalOption() и GetFunctionalInterfaceOption() връщат стойността на функционалната опция. Разликата между тях е, че първият метод ви позволява да посочите набор от параметри за функционални опции, а вторият метод връща стойността на функционална опция въз основа на параметрите, зададени за командния интерфейс.

Управляваният формуляр има свой собствен метод, който връща стойността на опцията за параметрите, посочени във формуляра - GetFormFunctionalOption().

Работа с параметри на функционални опции

Методите за работа с параметри на функционални опции ви позволяват да получите и зададете стойностите на параметрите на функционалните опции за команден интерфейс или конкретна форма. За да зададете стойностите на параметрите на функционалната опция, трябва да извикате съответната функция (SetInterfaceFunctionalOptionParameters() или SetFormFunctionalOptionParameters()), като й предадете като параметър структура, чийто ключ съответства на името на един от параметрите на функционалната опция, и чиято стойност съответства на стойността на параметъра. Извикването на горните методи автоматично ще актуализира съответната част от интерфейса.

Не е необходимо параметрите да бъдат посочени всички наведнъж; можете да промените стойността на конкретен параметър или набор от параметри избирателно. Но груповата настройка на стойности с едно повикване е по-ефективна.

За да получите стойности на параметри, трябва да извикате съответната функция (GetInterfaceFunctionalOptionParameters() или GetFormFunctionalOptionParameters()), която ще върне зададените параметри под формата на структура, където името на параметъра ще бъде ключ.

Функционалните опции са обект на метаданни, разположен в групата "Общи":

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

Да разгледаме един пример:

Нека създадем функционална опция " Счетоводство по складове".
Съхранение: посочва се полето, в което се съхранява стойността.
Можете да изберете константа, атрибут на директория или ресурс на информационен регистър.
Ще използваме константа.

Нека създадем константа " Водете счетоводство на складове" и го изберете в полето за съхранение. Тази константа ще отговаря за активирането и деактивирането на функционалната опция. Поставете отметка в квадратчето "Привилегирован режим при получаване." Това квадратче за отметка означава, че стойностите на функционалната опция ще бъдат получени в привилегирован режим :

Ние актуализираме, стартираме 1C Enterprise. Задайте стойността на константата = True:

В резултат на това имаме:

Когато задаваме константата = False, получаваме:

Имате въпрос или нужда от помощ от консултант?

И така, създадохме функционална опция, която контролира полета от типа DirectoryLink.Warehouse

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

Нека добавим към състава на документа подробности "Задаване на цени на артикул" - "Валута"

Под формата на документ в процедурите "When CreatedOnServer" и "OrganizationWhenChanged"
Нека добавим следния код:

Актуализираме конфигурацията и я стартираме.
Създаваме две организации и за една от тях поставяме отметка в квадратчето „Валутно счетоводство“

Какво получаваме в резултат? В резултат на използването на параметрите на функционалната опция получихме параметричен контрол на полето „Валута“ в документа „Задаване на цени на артикули“. Тези. за организацията "Алфа" ще се показва полето "Валута", а за организацията "Бета" полето "Валута" няма да се показва.
Нека се уверим в това. Отворете документа и опитайте да промените полето "Организация".
Когато зададете Организация = "Алфа", валутата се показва; промяна на "Бета" - валутата се премахва