Стойността на параметъра rls 1s не е зададена. Бележник на програмист. Създаване на RLS ограничение

Програмата 1C има вградена система за права за достъп, която се намира в Конфигуратор - Общи - Роли.

Какво характеризира тази система и какво е нейното основно предназначение? Тя ви позволява да опишете набори от права, които съответстват на позициите на потребителите или техните дейности. Тази системаправата за достъп са статични, което означава, че тъй като администраторът е задал правата за достъп на 1C, това е така. В допълнение към статичната има втора система за права на достъп - динамична (RLS). В тази система правата за достъп се изчисляват динамично, в зависимост от зададените параметри, в процеса на работа.

Роли в 1C

Към най-често срещаните настройки за сигурност в различни програмие така нареченият набор от разрешения за четене / запис за различни потребителски групи и в бъдеще: включване или изключване на конкретен потребител от групи. Такава система се използва например в операционна система Windows AD ( Активна директория). Системата за сигурност, използвана в софтуер 1C, получи името - роли. Какво е? Ролите в 1C са обект, който се намира в конфигурацията в клона: Общи - Роли. Тези 1C роли са групи, за които са присвоени права. В бъдеще всеки потребител може да бъде включен и изключен от тази група.

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

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

Имайте предвид, че всички права за достъп могат да бъдат разделени на две основни групи - това е „просто“ право и такова право с добавяне на „интерактивна“ характеристика. Какво се има предвид тук? А работата е следната.

В случай, че потребителят отвори някаква форма, например обработка, и в същото време щракне върху нея с мишката, тогава програмата на вградения език 1C започва да извършва конкретни действия, например изтриване на документи. За разрешаването на такива действия, извършвани от програмата, правата на 1C са отговорни, съответно, "просто".

В случай, че потребителят отвори дневника и започне да въвежда нещо самостоятелно от клавиатурата (например нови документи), тогава "интерактивните" 1C права са отговорни за разрешаването на такива действия. Всеки потребител може да има няколко налични роли наведнъж, след което се добавя разрешението.

RLS в 1C

Можете да разрешите достъпа до директорията (или документа) или да го забраните. Не можете просто да го включите малко. За тази цел има известно разширение на ролевата система 1C, което се нарича RLS. Това е динамична система за права за достъп, която въвежда частични ограничения за достъп. Например, само документи на определена организация и склад стават достъпни за вниманието на потребителя, той не вижда останалите.

Трябва да се има предвид, че системата RLS трябва да се прилага много внимателно, тъй като е доста трудно да се разбере нейната сложна схема и различните потребители могат да имат въпроси, когато например сравняват един и същ отчет, който се генерира от различни потребители. Нека разгледаме такъв пример. Избирате конкретна директория (организации, например) и конкретно право (четене, например), тоест разрешавате четене за ролята на 1C. В същото време задавате текста на заявката в дистанционния панел Data Access Restrictions, според който се задава False или True в зависимост от настройките. Обикновено настройките се съхраняват в специален информационен регистър.

Тази заявка ще се изпълни динамично (когато се направи опит за организиране на четене) за всички записи в директорията. Работи по следния начин: тези записи, за които е зададена заявката за сигурност - Вярно, потребителят ще види, но други не. Правата на 1C с установени ограничения са маркирани в сиво.

Операцията по копиране на идентични RLS настройки се извършва с помощта на шаблони. Като начало създавате шаблон, като го наименувате например MyTemplate, в който отразявате заявката за сигурност. След това в настройките за права за достъп посочете името на този шаблон по следния начин: "#MyTemplate".

Когато потребител работи в режим 1C Enterprise, когато се свързва с RLS, може да се появи съобщение за грешка като: „Недостатъчни права“ (например за четене на директорията XXX). Това показва, че RLS системата е блокирала четенето на някои записи. За да предотвратите появата на това съобщение отново, трябва да въведете думата РАЗРЕШЕНО в текста на заявката.

Всички настройки на потребителските права, които ще направим в рамките на тази статия, се намират в раздел 1C 8.3 „Администриране“ - „Настройки на потребител и права“. Този алгоритъмподобни в повечето конфигурации на управлявани форми. Програмата 1C Accounting ще бъде използвана като пример, но настройката на правата в други програми (1C UT 11, 1C ZUP 3, 1C ERP) се извършва по абсолютно същия начин.

Нека отидем в секцията „Потребители“ на прозореца с настройки. Тук виждаме две хипервръзки: „Потребители“ и „Настройки за влизане“. Първият от тях ви позволява да отидете директно до списъка с потребители на това информационна база. Преди да създадете нов потребител, разгледайте възможните настройки за влизане (хипервръзка вдясно).

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

Сега можете да преминете директно към добавяне на нов потребител към 1C. Можете да направите това, като щракнете върху бутона "Създаване", както е показано на изображението по-долу.

На първо място, нека посочим пълно име- "Антонов Дмитрий Петрович", а ние ще изберем от съответната директория индивидуален. Тук можете да посочите и отдела, в който работи наш служител.

Името за вход "AntonovDP" беше заменено автоматично като съкращение на пълното име "Antonov Dmitry Petrovich". Задайте парола и удостоверяване за 1C Enterprise. Тук също можете да посочите дали даден потребителсамопромяна на паролата.

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

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

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

След попълване на всички данни в потребителската карта - Антонов Дмитрий Петрович, ние ще ги запишем и ще преминем към настройка на правата за достъп, както е показано на фигурата по-долу.

Пред нас се отвори списък с предварително въведени в програмата профили за достъп. Поставете отметки в квадратчетата, които са задължителни.

Достъп до групови профили

Профилите на групата за достъп могат да бъдат конфигурирани от основната форма за настройка на потребители и права. Отидете в секцията „Групи за достъп“ и щракнете върху хипервръзката „Профили на групи за достъп“.

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

RLS: Ограничение за достъп на ниво запис

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

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

Нека отидем на профила на групата за достъп „Тестова група“, който създадохме по-рано. Фигурата по-долу показва, че след активиране на ограничението за достъп на ниво запис се появи допълнителен раздел „Ограничения за достъп“.

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

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

1C има вградена система за права за достъп (тази система се нарича 1C роли). Тази система е статична - тъй като администраторът е задал правата на 1C, така да бъде.

Освен това има динамична система за права на достъп (наречена - RLS 1C). В него правата на 1C се изчисляват динамично по време на работа на потребителя въз основа на зададените параметри.

Една от най-често срещаните настройки за сигурност в различни програми е набор от разрешения за четене / запис за потребителски групи и след това - включване или изключване на потребител от групи. Например подобна система се използва в Windows AD (Active Directory).

Такава система за сигурност в 1C се нарича Roles 1C. Roles 1C се намира в конфигурацията в клона Общи / Роли. 1C ролите действат като групи, за които са присвоени 1C права. След това потребителят се включва или изключва от тази група.

Като щракнете двукратно върху името на ролята 1C, ще отворите редактора на права за ролята 1C. Отляво има списък с 1C обекти. Изберете произволно и вдясно ще се покажат опции за права за достъп (най-малко: четене, добавяне, промяна, изтриване).

За горния клон (име текуща конфигурация) 1C административни права и достъп за стартиране на различни опции са инсталирани.

Всички права на 1C са разделени на две групи - „просто“ право и същото право с добавяне на „интерактивно“. Какво означава?

Когато потребителят отвори формуляр (например обработка) и натисне бутон върху него, програмата на вградения език 1C извършва определени действия, например изтриване на документи. За разрешението на тези действия (извършвани програмно) - "просто" отговарят правата на 1C.

Когато потребителят отвори дневник и започне да прави нещо от клавиатурата самостоятелно (например въвеждане на нови документи), това са „интерактивни“ 1C права.

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

Разделът за възможностите за задаване на права за достъп с помощта на роли е 1C обект. Тоест можете или да активирате достъпа до директорията, или да го деактивирате. Не може да се включи малко.

За това има разширение на ролевата система 1C, наречено 1C RLS. Това е динамична система от права за достъп, която ви позволява частично да ограничите достъпа. Например, потребителят вижда само документи за определен склад и организация и не вижда останалите.

Внимателно! Когато използвате объркваща схема RLS 1C, различни потребители може да имат въпроси, когато се опитват да проверят един и същ отчет, генериран от различни потребители.

Вземате определена директория (например организации) и определено право (например четене). Разрешавате четене за ролята на 1C. В панела за ограничаване на достъпа до данни задавате текста на заявката, който връща TRUE или FALSE в зависимост от настройките. Настройките обикновено се съхраняват в информационния регистър (например регистър с информация за конфигурацията Accounting UserAccessRightsSettingsUsers).

Тази заявка се изпълнява динамично (когато се опитвате да реализирате четене) за всеки запис в директорията. По този начин, за онези записи, за които заявката за защита е върнала TRUE, потребителят ще ги види, но останалите не.
Правата на 1C, които са предмет на ограничения на RLS 1C, са маркирани в сиво.

Копирането на същите настройки на RLS 1C се извършва с помощта на шаблони. Правите шаблон, наименувате го (например) MyTemplate, посочвате заявка за сигурност в него. След това в настройките за права за достъп до 1C посочете името на шаблона по следния начин: "#MyTemplate".

Когато потребител работи в режим 1C Enterprise, когато RLS 1C работи, той може да получи съобщение за грешка „Недостатъчни права“ (например за четене на директорията Xxx).

Това означава, че RLS 1C блокира четенето на няколко записа.

За да предотвратите появата на такова съобщение, е необходимо да използвате думата ALLOWED () в текста на заявката на вградения език 1C.

Например:

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

Какво е RLS?

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

За да можете да пишете заявки за RLS ограничения, трябва да създадете роля или да вземете съществуваща. Настройката на RLS в 1C 8.3 може да се използва за следните потребителски действия:

• Добавяне;
• четене;
• Премахване;
• промяна.

В допълнение към най-широките възможности за конфигуриране на достъпа, RLS има и недостатъци:

1. Изисквания за квалификация на разработчиците, тъй като заявката трябва да бъде написана на вградения език, като се вземат предвид правилата за синтаксис;
2. Невъзможност за бързо отстраняване на грешки в условията;
3. Ограничени възможности за описание на логиката: твърде сложни условия все пак ще трябва да бъдат записани в модулите на документи и директории;
4. Във версията клиент-сървър на бази данни е възможно имплицитно нарастване на таблиците, включени в заявката. Освен това е много трудно да се проследи този процес;
5. изисквания към ресурсите. RLS ограниченията консумират много клиентска машина и мощност на сървъра;
6. Малко документация е свободно достъпна.

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

Създаване на RLS ограничение

За да добавите RLS ограничение, трябва да намерите желаната роля и да я отворите с двукратно щракване.

Прозорецът, който се отваря, съдържа 2 раздела: „Права“ и „Шаблони за ограничаване“. За да наложите определени ограничения върху конкретно действие, трябва да го изберете и да кликнете върху зеления плюс в долната дясна част. Ще се появи ред, в който можем да зададем ограничения на 1C RLS на вградения език 1C.

Ако знаете синтаксиса на 1C (като опакото на ръката си), тогава можете да пишете директно в полето "Ограничение на достъпа". Разработчиците на 1C предоставиха възможност за отваряне на конструктора на заявки, който ще ви помогне и ще ви каже какво може да бъде направено ограничението. За да го отворите, трябва да кликнете върху бутона с три точки (Select) или F4 и ще се появи прозорец с бутона "Query Builder ...".

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

В раздела „Шаблони за ограничения“ се задават заявки, които са необходими при копиране на същите настройки на RLS в 1C 8.3. След като добавите вашия шаблон, можете да използвате името му в настройките за права за достъп.

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

Като заключение бих искал да отбележа, че тази статия е насочена към консултантите на разработчиците на 1C и може да помогне преди всичко на тези, които вече са имали опит в разработката на 1C:Enterprise. Въпреки привидната простота, познаването на семантиката и разбирането на структурата на бизнес процесите на вашето собствено предприятие или клиентска организация за правилното разпределение на правата изискват определено ниво на знания и опит.

Печат (Ctrl+P)

Ограничение за достъп до данни

Механизмът за ограничаване на достъпа до данни (известен още като RLS, Защита на ниво ред) ви позволява да управлявате правата за достъп не само на ниво обекти с метаданни, но и на ниво обекти на базата данни на 1C:Enterprise. Следните обекти на 1C:Enterprise могат да се използват за ограничаване на достъпа до данни:
● роли,
● параметри на сесията,
● функционални опции,
● привилегировани общи модули,
● ключова дума ПОЗВОЛЕНО в езика на заявката.
Споделянето на тези обекти ви позволява да осигурите максимална гъвкавост, когато е необходимо да се разграничат правата за достъп до данни между потребители, изпълняващи различни функции.
Ограничения за достъп до данни могат да бъдат наложени на следните операции с данни (права за достъп): четене (правото за четене), добавяне (правото за добавяне), модифициране (правото за промяна) и изтриване (правото за изтриване). Текущият потребител ще може да извърши исканата операция в следните случаи:
● За операциите за четене и изтриване обектът в базата данни трябва да отговаря на ограничението за достъп до данни.
● За операция за добавяне, ограничението за достъп до данни трябва да съответства на обекта, който планирате да запишете в базата данни.
● За операция за промяна, ограничението за достъп до данни трябва да съответства на обекта както преди промяната (за обекта, който да бъде прочетен), така и след промяната (за обекта, който да бъде записан).
Когато налагате ограничения за достъп до данни, имайте предвид, че може да се посочи само едно условие за операциите за промяна, добавяне и изтриване и повече от едно ограничение за достъп до данни може да се посочи за операция за четене. Това означава, че могат да се задават различни условия за четене на различни полета на обект, като при задаване на условие можете да посочите както името на конкретно поле, така и специалното поле Други полета. В първия случай условието ще се приложи само ако селекцията (която чете данните) съдържа поле, за което е зададено ограничението, а във втория случай ограничението ще се приложи към всички полета на обекта, с изключение на за полета, за които изрично са зададени ограничения.
Когато зададете ограничение за конкретно поле, това поле ще бъде прочетено, ако ограничението е изпълнено, а когато зададете ограничение за други полета, данните на обекта ще бъдат прочетени само ако ограничението е изпълнено за всички полета на обект, включени в заявката за четене на данни .
За обекти на база данни от следните типове могат да бъдат наложени различни ограничения различни видовепромени (добавяне, модифициране, изтриване):
● Планове за обмен,
● Наръчници,
● Документи,
● Планове видове характеристики,
● Сметкопланове,
● Планове на типове селища,
● Бизнес процеси,
● Задачи.
За следните типове обекти на бази данни е възможно да се наложат ограничения върху четенето не само на целия обект, но и на отделните му полета:
● Планове за обмен,
● Наръчници,
● Документи,
● Дневници на документи,
● Планове на характерни типове,
● Сметкопланове,
● Планове на типове селища,
● Информационни регистри,
● Бизнес процеси,
● Задачи.
ВНИМАНИЕ! При достъп до полетата на обектите на базата данни, използвайки свойствата на обектите на приложението от вградения език на 1C:Enterprise, се чете целият обект, а не само стойността на използваното поле. Изключение е, когато изгледът е получен, когато ще бъдат прочетени само стойностите на полетата, включени в генерирането на изгледа.
Ограниченията за достъп се съдържат в ролите, те могат да бъдат посочени за повечето обекти с метаданни и са написани на специален език, който е подмножество на езика за заявки.

Език за ограничаване на достъпа до данни

Ограниченията за достъп до данни са описани на специален език, който е подмножество на езика за заявки ( Подробно описаниеезик за заявки. Езикът за ограничаване на достъпа до данни има следните промени по отношение на езика на заявката:
● В заявка за ограничаване на достъпа до данни винаги има една таблица като източник на данни - това е таблицата на обекта, върху който е наложено ограничението (основният обект на ограничението).
● Описанието на заявката е съкратено. Езикът за ограничаване на достъпа до данни използва само секциите FROM и WHERE на езика за заявки. И така, описанието на езика на заявката е както следва:
ИЗБЕРЕТЕ [ПОЗВОЛЕНО] [РАЗЛИЧНО] [ ПЪРВО<Количество> ]
<Списък с полета за избор>
[ОТ <Список источников> ]
[КЪДЕТО<Условие отбора> ]
[ГРУПИРАЙ ПО <Поля группировки> ]
[ИМАНЕ<Условие отбора> ]
[ЗА СМЯНА [ <Список таблиц Най-високо ниво> ]]
Докато описанието на езика за заявка за ограничаване на достъпа до данни е както следва:
[Псевдоним на таблица на основния обект на ограничение]
[ОТ <Список источников> ]
[КЪДЕТО<Условие отбора> ]

Подзаявките, използвани в езика за ограничаване на достъпа до данни, имат ограничен набор от разрешени възможности;
● Можете да зададете параметри на сесията и функционални опции като елементи на условие;
● Навсякъде в заявка за ограничаване на достъпа до данни могат да се използват шаблони, за да се улесни писането на ограничения.
Основната част от ограничението е условието, което се оценява за всеки запис в таблицата на базата данни, който е предмет на ограничението за достъп до данни. Запис се счита за наличен, ако в резултат на условието за един запис на таблицата на основния обект на ограничението се получи непразна таблица (т.е. таблица с 1 или повече записи). Ако условието води до празна таблица, записът, за който условието е изпълнено по този начин, се счита за недостъпен. Освен това, промяна на записа на таблицата на основния обект на ограничение
се счита за валиден, ако записът не нарушава ограничението, посочено за правото, както преди, така и след извършване на операцията по промяна.

Полета на таблица

В ограниченията за достъп до данни можете да използвате:
● Таблични полета на обекта, за който е описано ограничението за достъп до данни.
Например, ако е наложено ограничение за четене на елементите на директорията Контрагенти, тогава полетата на директорията Контрагенти и нейните таблични части могат да се използват в ограничението. По-специално, най-простите ограничения за четене на елементите на директорията на контрагентите могат да изглеждат така:

WHERE Име = „Тухлена фабрика“
Или така:

КЪДЕТО Продукти. Име= „Тухлено червено“
Къде е продуктът таблична частСправочник контрагенти.
● Таблични полета на обекти, достъпни чрез връзки в основния ограничителен обект.
Например, ако атрибутът Първичен мениджър на директорията Контрагенти има тип връзка към директорията Потребители, тогава ограничението за достъп може да има например следната форма:

КЪДЕТО PrimaryManager.Code= "Иванов"
Или:

КЪДЕТО PrincipalManager.Individual.Name= “Петровски”
● Таблични полета на обекти, свързани с основния обект на ограничение чрез определени условия и изрази над тях.
Например, може да бъде наложено следното ограничение върху четенето на елементите на директорията на контрагентите:

Контрагенти
ОТ
Справочник.Изпълнители AS контрагенти
ЛЯВО ПРИСЪЕДИНЯВАНЕ Директория.ПотребителиКАК Потребители
SW = Users.Name
КЪДЕ = "Петровски"
Това ограничение използва полетата на елементите на директорията Users, свързани с този елемент от директорията Counterparties чрез стойността на полетата Name.

Подзапитвания

Подзаявките се използват за формиране на набори от записи, които могат да се използват:
● за свързване с таблицата на основния обект на ограничение;
● да се използва като операнд на операциите за сравнение IN или NOT IN.
Подзаявките могат да използват всяка от функциите на езика на заявката, с изключение на:
● оператор В ЙЕРАРХИЯ ;
● предлага РЕЗУЛТАТИ;
● резултатите от вложените заявки не трябва да съдържат таблични части;
● по-специално някои виртуални маси Остатъци и обороти.
В следния пример на ограничение за четене от директорията на контрагентите, подзаявка се използва като набор от записи за свързване към основния обект на ограничение:

Контрагенти
ОТ
Справочник.Изпълнители AS контрагенти
ЛЯВО ПРИСЪЕДИНЯВАНЕ
(ИЗБИРАМ
Потребители.Име, Потребители.Индивид
ОТ
Директория.ПотребителиКАК Потребители
КЪДЕТО
Потребители.Код> “Petechkin”) AS Потребители
НА Counterparties.MainManager.Name = Потребители.Име
КЪДЕТО Потребители.Име на физическо лице= “Петровски”
Следващият пример показва ограничение за четене от директорията PassportData на физически лица, в която се използва подзаявка в
като операнд на оператора за сравнение B:

КЪДЕТО
PassportDataIndividual.Individual AT
(ИЗБЕРЕТЕ РАЗЛИЧНО
Служители. ИндивидКАТО ИНДИВИДУАЛЕН
ОТ
Регистър на информация. Служители AS работници)
Ако трябва да получите данни от табличния раздел в подзаявката, тогава в секцията FROM на подзаявката трябва да получите директен достъп до табличния раздел. Например вместо:

ИЗБЕРЕТЕ връзка КАТО връзка.
Продукти. ИмеКАК Име на продукта
ОТ Справочник.Изпълнители
като заявка, вложена в ограничение, трябва да използвате:

Опции за сесия

Заявките за ограничения на достъпа до данни могат да включват параметри на сесията. Например за четене на елементите на директорията Имейл групиможе да се зададе следното ограничение за достъп:

КЪДЕТО Owner.AccountAccess.User = &CurrentUser
И Собственик.AccessAccount.Administration= ВЯРНО

CurrentUser е параметър на сесията

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

Заявките за ограничаване на достъпа до данни могат да включват функционални опции. Могат да се използват само независими от параметър функционални опции. Например, ако търсенето в номенклатурата има атрибут Главен склад, тогава ограничението за четене на този атрибут може да изглежда така:

WHERE &WarehouseAccounting = TRUE

Където Складовото счетоводство е функционална опция

Характеристики на употреба

В ограничения върху обекти на база данни от следните типове не могат да се използват всички полета на основния обект на данни на ограничението:
● в регистрите за натрупване ограниченията за достъп могат да съдържат само измервания на основния обект на ограничение;
● В счетоводни книги в ограничения можете да използвате само размери на баланса на основния обект на ограничението.
ЗАБЕЛЕЖКА. Ако в условията на ограничен достъп до данните от оборотния регистър на натрупването се използват измервания, които не са включени в сумите, тогава
при достъп до виртуалната таблица на оборотите не се използват съхранени суми и заявката се изпълнява изцяло по таблицата на движенията.

Действия за ограничаване на достъпа

Ограниченията за достъп се проверяват, когато се извършват съответните операции върху обекти на база данни (от диалогови прозорци, от вградения език, чрез заявки) и могат да действат по един от двата начина:
● Всички . Методът „всичко“ предполага, че някаква операция с данни (от диалогови прозорци, от вградения език или чрез заявки) трябва да бъде извършена върху всички обекти на база данни, подразбиращи се от тази операция. Ако такава операция трябва да прочете или модифицира обекти на база данни, за които не са изпълнени съответните ограничения за достъп, тогава операцията приключва.
се срина поради нарушение на достъпа.
● Разрешено. Методът „разрешено“ предполага, че когато се извършва операция върху данни, трябва да се четат само тези обекти на база данни, които отговарят на съответните ограничения за достъп. Обектите на базата данни, които не отговарят на ограниченията за достъп, се считат за липсващи по време на такава операция и не влияят на резултата от операцията.
Ограниченията за достъп до данни се налагат върху обектите на базата данни, когато 1C:Enterprise осъществява достъп до базата данни. Във версията клиент-сървър на 1C:Enterprise се прилагат ограничения върху сървъра на 1C:Enterprise.
Начинът на действие на ограниченията, избран за извършване на всяка операция с данни, се определя от целта на тази операция и степента на отговорност на нейните резултати. По-специално, методът "разрешен" се използва при показване динамични списъции някои други интерактивни дейности. Методът "all" се използва при извършване на всякакви операции с обекти на приложението от вградения език на 1C:Enterprise, включително всякакви промени в обекти на база данни. Следователно, например, може да е трудно да се конструира селекция за метода Select() на мениджъри на директории, документи и други, последвано от заобикаляне на резултата, ако е зададено достатъчно сложно ограничение за съответния обект, тъй като не всяко условие в ограничението на правата за достъп може да бъде адекватно представено като избор за метода Select().
В заявките можете да контролирате как работят ограниченията за достъп до данни. За да направите това, езикът на заявката предоставя ключова дума ПОЗВОЛЕН. Ако в заявката не е посочено РАЗРЕШЕНО, тогава ограниченията се прилагат по начин "всички". Ако е посочена думата ALLOWED, тогава се избира методът "allowed".
Важно е, ако ключовата дума ALLOWED не е посочена в заявката, тогава всички филтри, посочени в тази заявка, не трябва да са в конфликт с никое от ограниченията за четене на обектите на базата данни, използвани в заявката. Освен това, ако в заявката се използват виртуални таблици, тогава съответните филтри трябва да бъдат наложени върху самите виртуални таблици.
Пример:

ИЗБИРАМ
Информация за контакт SliceFirst.View
ОТ RegisterInformation.ContactInformation.SliceLast(, Тип = &Тип)
КАК Информация за контакт SliceFirst
КЪДЕТО
ContactInformationSliceFirst.Type = &Тип
При използване на обектната техника достъпът до данни в РАЗРЕШЕН режим не се поддържа. Предполага се, че обектната техника се използва за най-критичните операции с данни, включително тяхната промяна. За да получите всички данни с помощта на обектна технология, независимо от установените ограничения, можете да изпълните необходими действияв привилегирован модул или от името на потребител с пълни права. В обектната технология няма средства за получаване само на разрешени данни.

Ограничителен механизъм

Всяка операция върху данни, съхранявани в базата данни в 1C:Enterprise, в крайна сметка води до достъп до базата данни с някои
заявка за четене или промяна на данни. По време на изпълнението на заявки към базата данни вътрешните механизми на 1C:Enterprise налагат ограничения за достъп. при което:
● Генерират се списък с права (четене, добавяне, актуализиране, изтриване), списък с таблици на база данни и списък с полета, използвани от тази заявка.
● От всички роли на текущия потребител се избират ограничения за достъп до данни за всички права, таблици и полета, включени в заявката. Освен това, ако някоя роля не съдържа ограничения за достъп до данните на която и да е таблица или поле, това означава, че стойностите на задължителните полета от всеки запис са налични в тази таблица. С други думи, липсата на ограничение за достъп до данни означава наличие на ограничение
КЪДЕ Е ИСТИНАТА.
● Текущите стойности на всички параметри на сесията и функционални опции, участващи в избраните ограничения, се извличат.
Получаването на стойността на параметър на сесия от текущия потребител не изисква правото за получаване на тази стойност. Въпреки това, ако стойността на някакъв параметър на сесията не е зададена, тогава ще възникне грешка и заявката към базата данни няма да бъде изпълнена.
Извличането на функционални опции се влияе от привилегирован режим на свойството за извличане на функционалната опция.
Ако това свойство е изчистено, тогава текущият потребител трябва да има достъп за четене до обекта, в който се съхранява функцията.
● Ограниченията, получени от една и съща роля, се комбинират с операция И.
● Ограниченията, получени от различни роли, се редуват заедно.
● Конструираните условия се добавят към SQL заявките, с които 1C:Enterprise извиква СУБД. При достъп до данни от страна на условията за ограничаване на достъпа не се извършва проверка на правата (нито към обекти с метаданни, нито към обекти на база данни). Освен това механизмът за добавяне на условия зависи от избрания режим на работа на ограниченията "всички" или "разрешени".
начинът "всичко"
Когато се налагат ограничения чрез метода "всички", към SQL заявките се добавят условия и полета, така че 1C:Enterprise да може да получи информация дали данните, които са забранени за дадения потребител, са били използвани в процеса на изпълнение на заявка към база данни или не . Ако са използвани забранени данни, тогава заявката се прекъсва. Налагането на ограничения за достъп по метода „всеки” е схематично показано на фиг. едно:

Ориз. 1. Методът "всичко".

"Разрешен" метод
Когато се налагат ограничения с помощта на метода „разрешено“, такива условия се добавят към SQL заявките, така че записите, забранени за текущия потребител, да не влияят на резултата от заявката. С други думи, когато се налагат ограничения в режим „разрешено“, записите, забранени за този потребител, се считат за липсващи, което е схематично показано на фигура 3.

Други обекти, свързани с ограниченията за достъп до данни

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

Ако за общ модул е ​​поставена отметка в квадратчето Привилегирован, тогава изпълнението на процедурите и функциите на този модул придобива важни специфики:
● Във версията клиент-сървър на 1C:Enterprise само модулът, който работи на сървъра, може да бъде привилегирован.
● Изпълнението на процедури и функции на привилегирован модул и всичко, което се извиква от тях се извършва при изключена система за ограничаване
права върху обекти с метаданни и данни. Така от привилегирован модул може да се извърши всяка операция
всякакви обекти, дори ако текущият потребител няма съответните права.
Привилегированите модули са за първоначална инсталациястойности на параметрите на сесията, използвани в ограниченията за достъп до данни.
Все още често срещаните модули могат да се използват за някои холистични действия върху данни от потребител с ограничени права.
Например, ако функциите на потребителя включват въвеждане и публикуване на документи, но потребителят не трябва да има достъп до данни, които са засегнати от публикуването на документ, тогава изпълнението на операцията по публикуване може да бъде преместено в привилегирован модул. Това ще позволи на потребителя да публикува документи, без да му предоставя права върху друга информация (например регистри).
Привилегирован режим
Възможно е програмно задаване на привилегирован режим при работа с данни. Инсталиране на софтуерпривилегирован режим
може да се наложи в случай на масивни операции с данни от информационната база и няма смисъл да се проверяват правата за достъп до данни.
За описание на привилегирован режим вижте тук.

Използване на препроцесора

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

#АКО<Выражение>#ТОГАВА
#ELSEIF<Выражение>#ТОГАВА
#В ПРОТИВЕН СЛУЧАЙ
#ЕНДЕСИ
<Выражение>- произволни булев изразна вграден език, резултатът от който е от тип Boolean. Изразът може да съдържа:
● операции за сравнение<, >, <=, >= , =, <> ;
● логически операции И, ИЛИ, НЕ ;
● Параметри на сесията - Синтаксисът е &Параметър, където Параметър е името на параметъра на сесията.
Ако резултатът от израза на оператора #IF или #ELSEIF е True, тогава текстът след ключовата дума #THEN се поставя в получения текст на оператора за ограничаване на достъпа. Ако изразът се изчисли като False, тогава текстът след ключовата дума #THEN не се поставя в текста на инструкцията за ограничаване на достъпа. Текстът след оператора #ELSE ще бъде поставен в резултантния текст за ограничение на достъпа, ако нито едно от предишните условия не е изпълнено.
ЗАБЕЛЕЖКА. Ако текстът за ограничение на достъпа до данни съдържа инструкции на предпроцесора, тогава такова ограничение не преминава проверка на синтаксиса при редактиране и не може да бъде променено с помощта на конструктора.
Пример:

#АКО &Текущ потребител<>“Климова” #ТОГАВА
<текст ограничения доступа>
#ЕНДЕСИ
Тук Текущия потребител- сесиен параметър от тип DirectoryLink.Users.
Тази конструкция означава, че условието за задаване на ограничения за достъп ще бъде проверено за всички потребители от директорията, с изключение на потребителя Klimova.

Текстови шаблони за ограничаване на достъпа

Една роля може да съдържа списък с шаблони за ограничаване на достъпа, които са описани в раздела Шаблони за ограничаване на формуляра за роля. Освен това шаблоните за ограничаване на достъпа могат да се редактират в редактора за групово редактиране на ограничения за достъп и шаблони.
Всеки шаблон за ограничаване на достъпа има име и текст. Името на шаблона следва обичайните правила за имена, приети в системата 1C:Enterprise.
Текстът на шаблона съдържа част от текста на езика за ограничаване на достъпа до данни и може да съдържа параметри, които са маркирани със символа
“#”.
След характера “#” може да последва:
● Един от ключови думи:
● Параметър, следван от номера на параметъра в шаблона в скоби;
● CurrentTable – означава вмъкване в текста на пълното име на таблицата, за която се изгражда ограничението;
● CurrentTableName– обозначава вмъкване в текста на пълното име на таблицата (като низова стойност, в кавички), към която се прилага инструкцията, в текущата версия на вградения език;
● NameCurrentAccessRight - съдържа името на правото, за което се извършва текущото ограничение: ПРОЧЕТЕТЕ/ПРОЧЕТЕТЕ, ДОБАВЯТЕ/ВМЪКВАТЕ, ПРОМЕНЯТЕ/
АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ;
● име на параметър на шаблона – означава вмъкване на ограничението на съответния параметър на шаблона в текста;
● Символ “#” – означава вмъкване на един символ “#” в текста.

Изразът за ограничаване на достъпа може да съдържа:

● Модел за ограничаване на достъпа, който е посочен във формата
#TemplateName("Стойност на параметър на шаблон 1", "Стойност на параметър на шаблон 2", ...). Всеки параметър на шаблона е ограден в двойни кавички. Ако трябва да зададете двойна кавичка в текста на параметъра, използвайте две двойни кавички.
● Функция StrContains(Къде търсим, какво търсим). Функцията е проектирана да търси срещане на WhatLooking for в низа WhereLooking for. Връща True, ако съвпадението бъде намерено, False в противен случай.

● Операторът + за конкатенация на низове.
За удобство при редактиране на текста на шаблона, в раздела Шаблони за ограничения във формуляра за роли щракнете върху бутона Задаване на текст на шаблон. В диалоговия прозорец, който се отваря, въведете текста на шаблона и щракнете върху OK.
Системата 1C:Enterprise проверява синтаксиса на текстовете на шаблоните, проверява синтаксиса за използване на шаблони и макрозамества текстовете на шаблоните за ограничаване на достъпа до роли в текста на заявката.
Макро заместването на шаблон е:
● замяна на появявания на параметри в текста на шаблона със стойности на параметри от израза за използване на шаблона в текста на ограничението;
● при замяна на израза за използване на шаблона в текста на заявката с получения текст на шаблона.
При извикване на конструктора на заявка за условие, което съдържа шаблони за ограничаване на достъпа, се издава предупреждение за подмяна на всички шаблони.
Следват примери за модели на ограничения:

За да управлявате гъвкаво потребителския достъп до данни в съответствие с функциите, когато задавате ограничения за достъп до данни, се препоръчва
се придържат към следните принципи:
● Трябва да изберете набор от информация (може да зависи от текущия потребител), за която е подходяща предварителна подготовка. Избраната информация трябва, от една страна, да опрости ограниченията за достъп до данни, доколкото е възможно, и, от друга страна, не трябва да бъде твърде голяма. Разпределете го по параметри на сесията.
● Задайте стойностите на параметрите на сесията в манипулатора SetSessionParameters() на модула на сесията.
● Задайте ограничения за достъп до тези данни, за които е обосновано (данните са секретни или най-важните за поддържане на целостта на системата). Имайте предвид, че задаването на ограничения за достъп може да забави всеки достъп до тези данни. Твърде сложните ограничения също могат да доведат до забавяне.
● Ако е необходимо да се осигури извършването на определен ограничен брой операции с данни от потребителя, на когото е неуместно да се дава пълен достъп до тези данни, преместете тези действия в привилегировани модули или изрично активирайте и деактивирайте привилегирования режим в подходящите места от програмния код.
● Различните проверки, които системата извършва при писане на обекти, са достъпни в привилегирован режим.

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

● за директории при проверка на родител, собственик и уникалност на кода;
● за документи, бизнес процеси и задачи при проверка на уникалността на номера;
● за обменни планове е деактивиран при проверка на уникалността на кода;
● за сметкопланове и планове на характерни типове при проверка на майка и уникалност на кода.

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

● Ако са зададени ограничения за достъп до данни за таблица с обекти и в заявката за данни се използва съединение с такава таблица, тогава условието за свързване (раздел за заявка на софтуер) не позволява използването на табличната част на обекта с посоченото ограничение за достъп.
● Ако дадена заявка посочва таблица, която не използва нито едно поле в заявката, тогава всички ограничения за достъп до данни се налагат на тази таблица. Например молба ИЗБЕРЕТЕ КОЛИЧЕСТВО(*) ОТ Указател. Контрагентище се изпълни при спазване на всички ограничения за достъп, посочени за тестовата директория. Ограниченията се налагат "чрез ИЛИ". Това означава, че всички записи, които са достъпни при поне едно условие, ще бъдат налични. Ако не са зададени условия за някои полета, тогава заявката ще бъде изпълнена за всички записи в таблицата.
Ако заявката използва таблица от най-високо ниво, тогава ограниченията, посочени за колоните на вложените таблици, не се прилагат.
Ако дадена заявка използва вложена таблица, тогава ограниченията се прилагат както за вложената таблица, така и за таблицата от най-високо ниво.
Например молба ИЗБЕРЕТЕ КОЛИЧЕСТВО(*) ОТ Директория.Контрагенти.Споразуменияще се изпълни, като се вземат предвид всички ограничения за справочника Контрагенти, както и като се вземат предвид ограниченията, свързани с табличната част на Договора.

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

Конструктор за ограничаване на достъпа до данни

За да извикате конструктора в полето на таблицата Ограничения за достъп до данни, в колоната Ограничение на достъпа превключете в режим на редактиране и
щракнете върху бутона за избор и във формуляра, който се отваря, щракнете върху бутона Query Builder….
Формата на конструктора се показва на екрана:

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

В раздела Връзки се формират условия, които се налагат на връзките между полетата на таблицата. За да въведете ново условие, щракнете върху бутона Добавяне и изберете една от таблиците в колоната Table1. В колоната Table2 изберете таблицата, чиито полета са свързани с полетата на първата. Под списъка с условия има контроли, които формират условието за свързване на таблици.
Ако е избран прост тип условие, тогава свързаните полета на посочените таблици се избират в Поле1 и Поле2 и се задава условието за сравнение. Ако са избрани полета, които не се сравняват, следният текст се показва в реда на списъка с условия в колоната Условие на връзката: Неправилно попълнено условие.
В раздела Условия, ако е необходимо, трябва да посочите условията, при които ще бъдат избрани изходните данни.

За всяко избрано поле трябва да изберете вида на условието и да посочите името на параметъра. Параметър на сесията е разрешен като параметър. Разрешени са множество условия. В този случай в колоната Условие на полето на таблицата с условия текстът на условието се показва на няколко реда.
По всяко време при създаване на заявка текстът на заявката може да бъде прегледан чрез натискане на бутона Заявка.

Пакетно редактиране на ограничения за достъп и шаблони

Режимът на групово редактиране на ограничения за права за достъп и шаблони се извиква от командата Всички ограничения за достъп от контекстното меню на клон Роли. Формулярът, който се отваря, съдържа два раздела: Ограничения за достъп и Шаблони за ограничения.

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

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

Отметка Модели на ограниченияможете да видите всички шаблони за ограничаване на достъпа, налични в решението на приложението, докато в таблицата се показват само първите 10 реда от самия текст на шаблона, които завършват със символа „…“, ако текстът на шаблона е повече от 10 реда. Прозорецът за редактиране на шаблон ще покаже пълния текст на шаблона.

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