1c изберете позволено. Бележник на програмиста. Ограничения за достъп на рекордно ниво

Желязо

Конфигурационният обект „роля“ дава набор от права за операции (действия) над конфигурационни обекти.

Роля "Пълни права".

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

Това, което я отличава от другите роли, е наличието на правото „Администриране“.

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

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

Защита на ниво ред (RLS) – ограничение на ниво запис.

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

роли,
параметри на сесията,
функционални опции,
привилегировани споделени модули,
ключова дума ПОЗВОЛЕНО в езика на заявката.

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

Техническо изпълнение на ограниченията за достъп в 1C

1C генерира заявка към СУБД. Сървърният клъстер добавя раздел WHERE към заявката, която съдържа текста на условието за ограничаване на достъпа чрез RLS, след което тази заявка се изпраща до СУБД, извлечените данни се връщат на клиента 1C.

Този механизъм ще работи за всяка заявка от клиента:

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

Такова изпълнение на механизма значително влияе върху производителността.

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

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

а) Привилегирован модул е общ модул с флаг „Привилегирован“ в свойствата.

Неговата особеност е, че кодът в него се изпълнява без никакъв контрол на правата за достъп, включително RLS.

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

Привилегировано отношение при провеждане
Привилегирован режим при анулиране на транзакция

Б) Метод SetPrivilegedMode()

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

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

Той ще работи до реда за деактивиране на този режим или до края на процедурата/функцията

(Вярно);

// всеки код тук ще бъде изпълнен без контрол на правата и RLS

SetPrivilegedMode(Лъжа); // или край на процедура/функция

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

Ако в процедура или функция извиква метод SetPrivilegedMode(False) направи повече от извиквания на метод SetPrivilegedMode(True), тогава ще бъде хвърлено изключение

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

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

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

Естествено възниква въпросът: защо тогава изобщо да се задават ограничения за достъп, ако могат да бъдат толкова лесно заобиколени?

Безопасен режим.

Да, можете да пишете външна обработка с привилегирован режим на изпълнение и да разтоварвате/повредите данни. За да предотврати това, системата има метод за глобален контекст

SetSafeMode().

Безопасният режим, наред с други неща, игнорира привилегирован режим.

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

При извършване на забранени операции се хвърля изключение по време на изпълнение.

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

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

RLS може да бъде конфигуриран само за права:

чета (избирам)
добавяне (вмъкване)
промяна (актуализация)
Изтрий

За операции за четенеи изтриване, обект, който се намира в базата данни, трябва да отговаря на ограниченията за достъп до данни.

За операцията за добавянеОграничението за достъп до данни трябва да съответства на обекта, който се планира да бъде записан в базата данни.

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

За всички останали права няма такава опция.

Нека добавим ново ограничение за правото на „четене“ на директорията „Номенклатура“. Ще се отвори списък с полета, за които можете да конфигурирате добавеното ограничение.

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

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

* Функция: за права за добавяне, промяна, изтриване:

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

Може да има само едно ограничение.

За правото „Четене“ можете да конфигурирате няколко условия, които ще бъдат комбинирани с логическия оператор „И“.

Не всички полета на основния обект на данни за ограничение могат да се използват в ограничения за следните типове обекти на база данни:

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

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

Механизъм за налагане на ограничения на достъпа.

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

Генерира се списък с права(четене, добавяне, промяна, изтриване), списък с таблици на база данни и списък с полета, използвани от тази заявка.
От всички роли на текущия потребител са избрани ограничения за достъпкъм данни за всички права, таблици и полета, включени в заявката. Освен това, ако ролята не съдържа ограничения за достъп до данните на таблица или поле, това означава, че стойностите на задължителните полета от всеки запис са налични в тази таблица. С други думи, липсата на ограничение за достъп до данни означава наличие на ограничение КЪДЕ Е ИСТИНАТА.
Извлича текущите стойности на всички параметри на сесията и функционални опцииучастващи в избраните ограничения.

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

Ограниченията, получени от една роля, се комбинират с помощта на операцията И.

Ограниченията, получени от различни роли, се комбинират с помощта на операцията ИЛИ.

Конструираните условия се добавят към SQL заявките, с които 1C: Enterprise осъществява достъп до СУБД. При достъп до данни от условия за ограничаване на достъпа не се извършва проверка на правата (нито за обекти с метаданни, нито за обекти от база данни). Освен това механизмът за добавяне на условия зависи от избрания метод на действие на ограниченията „всички“ или „разрешени“.

*Характеристика: Ако даден потребител има достъп до няколко роли с конфигурирани ограничения на ниво запис за един обект, тогава в този случай условията на ограниченията се добавят с помощта на логическата операция „ИЛИ“. С други думи, правомощията на потребителя са кумулативни.

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

Метод "всичко".

Когато се налагат ограничения чрез метода „всички“, към SQL заявките се добавят условия и полета, така че 1C:Enterprise да може да получи информация дали по време на изпълнение на заявка към база данни са използвани данни, които са били забранени за даден потребител или не. Ако са използвани забранени данни, заявката ще се срине поради нарушение на достъпа.

Налагането на ограничения за достъп чрез метода „всички“ е схематично представено на фигурата:

„Разрешен“ метод.

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

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

Във версията клиент-сървър на 1C:Enterprise се прилагат ограничения върху сървъра на 1C:Enterprise.

Въпреки това, тази опция (ПОЗВОЛЕНО) няма да работи, ако в заявка препращаме към таблица, за която не са конфигурирани ограничения за достъп, но която съдържа препратки към редове на таблица с конфигурирани ограничения. В този случай резултатът от заявката ще покаже „<Объект не найден>......" вместо стойността на референтното поле.

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

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

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

Практика 1. Създател на заявки в настройките на RLS.

Нека съставим текста на секцията „WHERE“ в заявката към директорията. Можете да използвате конструктора на заявки.
Дизайнерът има разголен външен вид.

Раздел „Таблици“.

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

Можете също да изберете други таблици и да настроите различни връзки между тях в раздела „Връзки“.

Раздел "Условия"

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

Нека добавим условия към атрибута “Цена” на номенклатурната директория за право на “четене” на всички полета на таблицата.

„Номенклатура WHERE Номенклатура. Цена > 500“

Нека видим как работи това просто правило. Таблицата с директории съдържа следните елементи:

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

Групите също изчезнаха. Нека променим текста на ограничението

„Номенклатура WHERE Номенклатура. Цена > 500

ИЛИ номенклатура. Това е група"

Е, това е, което ви трябва.

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

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

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

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

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

След настройка на ограничението за достъп, показването на реда в списъка с права се промени - стана сиво и се появи икона.

Ограничения при настройка на достъп (RLS).

Няма раздел Резюме;
Виртуалните регистрови таблици не могат да бъдат достъпни;
Не можете да използвате параметри изрично;
Може да се използва във вложени заявки всякакви>/span> инструменти за език за заявки, с изключение на:
- оператор В ЙЕРАРХИЯ;
- РЕЗУЛТАТИ предложения;
- вложени резултати от заявка не трябва да съдържа части от таблица>/span>;
- виртуални маси, по-специално баланси и обороти

Практика 2. Номенклатура с текуща цена.

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

Решение:

Добавяме ново правило за ограничаване на достъпа за директорията „Номенклатура“ с право „четене“.
Изберете „други полета“.
В конструктора добавяме вложена заявка. В него изберете таблицата с информационен регистър „Цени на артикулите“.
Няма раздел „поръчка“ - това е функция на дизайнера на заявки за изграждане на заявка за ограничаване на достъпа.
В раздела „Разширени“ задайте „първите 999999999“, появява се разделът „поръчка“.
Настройваме подреждане по полето „Период“ в низходящ ред.
След това създаваме връзка между главната таблица и подзаявката чрез препратка.

Шаблони за ограничаване на достъпа.

Практика 3. Ограничение за „контрагенти“ по стойност в константа.

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

Освен това трябва да зададете ограничение за всички обекти, които използват директорията „Контрагенти“ в подробностите.

Решение

За директорията „Контрагенти“ ще настроим ограничение за правото „четене“, като добавим вложена заявка към константата в секцията „Условия“. Не забравяйте, че това е група.

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

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

Нека копираме и леко променим текста на условието RLS от директорията „Контрагенти“. Това трябва да се направи толкова пъти, колкото са откритите предмети.

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

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

Можете да добавите всяка част от текста за ограничаване на достъпа към шаблона. Шаблонът се извиква с помощта на символа „#“. Например, #TemplateCounterparty.

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

Нека добавим текста след думата WHERE към шаблона „Contractor Template“, с изключение на текста за EtoGroup.

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

Нека продължим с решаването на задача 2.

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

Нека променим името на основната таблица в текста на шаблона на „#CurrentTable“

"#CurrentTable" е предварително дефиниран параметър.

И чрез точка посочваме номера на входния параметър - “.#Parameter(1)

„#Параметър“ също е предварително дефинирана стойност. Може да съдържа произволен брой входни параметри. Те се адресират по сериен номер.

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

За документа следното:

„Продажби на стоки WHERE #TemplateCounterparty („Counterparty“)“

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

Основна таблица - Номенклатура

Текстът на шаблона е:

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

Текстът на шаблона съдържа част от текста на езика за ограничаване на достъпа до данни и може да съдържа параметри, които са маркирани със символа „#“.

Символът "#" може да бъде последван от:

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

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

Шаблон за ограничаване на достъпа, който е посочен във формата #TemplateName("Стойност на параметър на шаблон 1", "Стойност на параметър на шаблон 2",...). Всеки параметър на шаблона е ограден в двойни кавички. Ако трябва да зададете двойна кавичка в текста на параметъра, трябва да използвате две двойни кавички.
Функция StrContains(WhereWeLook, WhatWeLook). Функцията е предназначена да търси срещане на низа WhatWeLook в низа WhereWeLook. Връща True, ако срещането е намерено, и False в противен случай.
Операторът + е за конкатенация на низове.

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

Те не могат да бъдат инсталирани с помощта на SetParameter()или нещо подобно.

Параметрите в този случай са:

Опции за сесия
Функционални опции

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

Практика 4. Достъп до „вашите“ контрагенти

Необходимо е да конфигурирате ограничаване на достъпа на текущия потребител до „техните“ контрагенти.

Има директория „Потребители“, директория „Контрагенти“, документи с реквизитите „Контрагент“.

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

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

Възможни опции:

Установяване на връзки между потребител и контрагент

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

Възможни решения на проблема:

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

Решение.

Нека създадем нов параметър на сесията "CurrentUser" и да го попълним в модула на сесията.

Да създадем регистър на информацията „Съответствие на управители и изпълнители”

Нека създадем нова роля и в нея ново ограничение за достъп до документа “Фактура”.

В текста на заявката ще свържем основната таблица с информационния регистър за Account = Account и Manager = &CurrentUser. Тип връзка Вътрешен.

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

Проверка - ограниченията работят

* Характеристика: Ако промените списъка с потребителски контрагенти в регистъра, ограниченията за достъп ще влязат в сила незабавно, без да рестартирате потребителската сесия.

Практика 5. Дата на забрана за промени.

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

Нека създадем регистър на информацията „Дати на забрана за промени“ с измерение Потребител, ресурс Дата на забрана.

Нека изградим логиката на решението по следния начин:

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

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

Документация
Периодични информационни регистри

Нека създадем нова роля „Ограничения по дата на забрана на промените“.

В него за документ „Фактура” за право „промяна” ще добавим ново ограничение за достъп.

Посочваме настройката за всички полета.

Текстът на ограничението е:

ReceiptInvoice FROM Document.ReceiptInvoice КАТО ReceiptInvoice

Променете датите на забрана като дата на забрана
ОТ

ВЪТРЕШНО СЪЕДИНЯВАНЕ (ИЗБЕРЕТЕ
MAX(Промяна на забранените дати.Потребител) КАТО потребител
ОТ
Регистър на информацията. Дати на забрана за промени КАТО дати на забрана за промени
КЪДЕТО
(Промяна на забранени дати.Потребител = &Текущ потребител
ИЛИ Дати Забранени промени.Потребител = VALUE(Directory.users.EmptyLink))) AS VZ_User
ПО Дата на забрана на промените.User = VZ_User.User) AS NestedQuery
Софтуерна разписка Invoice.Date > Вложена Query.Ban Date

Да проверим - ограничението работи.

Използване на инструкции за препроцесор

#Ако Условие1 #Тогава

Заявка за фрагмент 1

#ElseIf Условие2 #Тогава

Искане на фрагмент 2

#В противен случай

Заявете фрагмент 3

#EndIf

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

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

Недостатъкът е, че конструкторът на заявки няма да работи с такъв текст.

*Особеност:

За разлика от инструкциите към препроцесора на вградения език в текстовете за ограничаване на достъпа, преди оператора Then трябва да поставите хеш - #Then

Практика 6. Превключете „Използване на RLS“

Нека допълним нашата система от ограничения с превключвател, който включва/изключва използването на ограничения на ниво запис.

За да направим това, ще добавим константа и параметър на сесия, наречен „UseRLS“.

Нека напишем в модула на сесията, за да зададем стойността на параметъра на сесията от стойността на константата.

Нека добавим следния код към всички текстове за ограничаване на достъпа:

„#Ако &UseRLS #Тогава….. #EndIf“

Проверяваме - всичко работи.

Сега обаче след включване на флага „използване на радар“, промените няма да влязат в сила веднага. Защо?

Тъй като параметърът на сесията се задава при стартиране на сесията.

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

Край на първата част.

20.09.2014

Има директива "Разрешено" в езика на заявката. Той е предназначен да позволи на платформата да филтрира записи, за които потребителят няма права, когато задава ограничения на ниво запис на базата данни.

Изглежда, че е по-добре винаги да използвате тази директива в заявки. Ще твърдя, че това не е така. Също така ще твърдя, че ако е възможно, трябва да избягвате да го използвате, ето защо.

Да кажем, че правим отчет за взаимни разплащания лица. Потребителят има права за една организация, има повече от една организация в базата данни и базата данни има разрешени ограничения на ниво запис. Също така в базата данни има регистър „Взаимни разчети” с измерения „Организация” и „Физическо лице”. Ако има заявка в системата

"Избирам

организация,

Индивидуален

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

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

"Избирам

организация,

Индивидуален

(Избирам

Организация

Индивидуален)

От Набирателния регистър

(Където

Организация

Индивидуален)

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

Можете да попитате отново - „Защо не трябва да използвате директивата Allowed?“ Това незабавно налага избор и ще защити потребителя от ненужни съобщения!

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

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

Но как можете да избегнете грешката от „срива“ на програмата, ако нямате достатъчно права?

Да, много е просто, трябва да използвате командата „Опитай“, ето пример:

опит

Request.Run();

Изключение

Доклад(Описание на грешка());

EndAttempt;

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

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

Можете да се запознаете с нюансите на настройката на RLS в обособени поделенияв нашата статия.

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

1C Функции на езика за заявки

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

1. функция ВРЕМЕ ЗА СРЕЩА - тази функциясъздава постоянно поле от тип "Дата".

Синтаксис: ВРЕМЕ ЗА СРЕЩА(<Год>,<Месяц>,<День>,<Час>,<Минута>,<Секунда>)

Пример за употреба:

2. Функция DATE DIFFERENCE- връща разликата между две дати в едно от измеренията (година, месец, ден, час, минута, секунда). Измерването се предава като параметър.

Синтаксис: DIFFERENCEDATE(<Дата1>, <Дата2>, <Тип>)

Пример за употреба:

Query.Text = "ИЗБЕРЕТЕ | DIFFERENCEDATE(DATETIME(2015, 4, 17), DATETIME(2015, 2, 1), DAY) | AS Qty.Days";

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

Синтаксис: VALUE(<Имя>)

Пример за употреба:

Request.Text = "SELECT //предварително дефиниран елемент | VALUE(Directory.Currencies.Dollar) AS Dollar, //празна връзка | VALUE(Document.Receipt of Goods and Services.EmptyLink) AS Receipt, //трансферна стойност | VALUE(Transfer . Юридическо лице. Физическо лице) AS Физическо лице, //предварително определен акаунт VALUE(Сметкоплан. Самосчетоводни материали) AS Account_10" ;

4. SELECT функция- имаме пред нас аналог на конструкцията IF, който се използва в кода, само този се използва в 1C заявки.

Синтаксис: ИЗБОР КОГА<Выражение>ТОГАВА<Выражение>В ПРОТИВЕН СЛУЧАЙ<Выражение>КРАЙ

Пример за употреба:

Request.Text = //ако сумата е повече от 7500, тогава трябва да има отстъпка от 300 рубли, //така че ако условието е задействано, тогава функцията //връща Сума - 300 //в противен случай заявката просто ще върне Сума "ИЗБЕРЕТЕ | ИЗБЕРЕТЕ | КОГАТО TCReceipts.Amount > 7500 | ТОГАВА TCReceipts.Amount - 300 | ДРУГО TCReceipts.Amount | КРАЙ КАТО AmountWithDiscount | ОТ |

5. Функция EXPRESS- позволява ви да изразите постоянно поле с определен тип.

Синтаксис: EXPRESS(Име на поле КАТО Име на тип)

Пример за употреба:

Има ли друг вариант за използване на функцията EXPRESS в полета от смесен тип, къде се срещат? Най-простият пример е „Регистраторът“ за всеки регистър. Така че защо може да се наложи да квалифицираме типа в регистратора? Да разгледаме ситуацията, когато изберем полето "Номер" от регистратора, от коя таблица ще бъде избран номерът? Верният отговор от всички! Следователно, за да работи нашата заявка бързо, трябва да посочим явен тип с помощта на функцията EXPRESS

Пример за употреба:

Query.Text = "SELECT | EXPRESS(Nomenclature.Comment AS Line(300)) AS Comment, | EXPRESS(Nomenclature.Sum AS Number(15,2)) AS Sum |FROM | Directory.Nomenclature AS Nomenclature";

6. Функция ISNULL(алтернативно изписване ISNULL) - ако полето е от тип NULL, то се заменя с втория параметър на функцията.

Синтаксис: ISNULL(<Поле>, <ПодставляемоеЗначение>)

Пример за употреба:

Също така имайте предвид, че е препоръчително ВИНАГИ да замествате типа NULL с някаква стойност, т.к сравнението с тип NULL винаги връща FALSE, дори ако сравните NULL с NULL. Най-често NULL стойностите се формират в резултат на свързване на таблици (всички видове съединения, с изключение на вътрешни).

Query.Text = //Изберете целия артикул и неговите баланси //ако няма баланс в някой артикул, тогава ще има поле //NULL, което ще бъде заменено със стойността 0 "SELECT | No. Link, | ISNULL (ProductsInStockRemaining, 0) AS Directory.Nomenclature AS No. LEFT CONNECTIONAccumulations.GoodsInWarehousesRemainings |PO (GoodsInWarehousesRemainings = No.Link)";

7. Функция ПРЕДСТАВЯНЕ- позволява ви да получите представяне на полето за заявка.

Синтаксис: ПРОИЗВОДИТЕЛНОСТ(<НаименованиеПоля>)

Пример за употреба:

Query.Text = "SELECT | REPRESENTATION(FreeRemainingRemains.Nomenclature) AS Nomenclature, | REPRESENTATION(FreeRemainingRemaining.Warehouse) AS Warehouse, | FreeRemainingRemaining.InStockRemaining |ОТ |Регистър за натрупване.FreeRemaining.Remaining AS FreeRemainingRemaining ";

Конструкции в езика за заявки 1C

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

1. Строителство ЛИНК- е логически оператор за проверка на референтен тип. Най-често се среща при проверка на поле от сложен тип спрямо определен тип. Синтаксис: ВРЪЗКА<Имя таблицы>

Пример за употреба:

Request.Text = //ако типът стойност на записващото устройство е разписка на документа, //тогава заявката ще върне „Получаване на стоки“, в противен случай „Продажби на стоки“ „ИЗБЕРЕТЕ | ИЗБЕРЕТЕ | КОГАТО Remainings.Registrar LINK Документ.Получаване на стоки и Услуги |. "Потребление" |. ОТ Регистър на натрупване КАТО.

2. Дизайн МЕЖДУ- този оператор проверява дали стойността е в зададения диапазон.

Синтаксис: МЕЖДУ<Выражение>И<Выражение>

Пример за употреба:

3. Конструкция Б и Б ЙЕРАРХИЯ- проверка дали стойността е в прехвърления списък (масиви, таблици със стойности и др. могат да се прехвърлят като списък). Операторът IN HIERARCHY ви позволява да видите йерархията (пример за използване на сметкоплана).

Синтаксис: IN(<СписокЗначений>), В ЙЕРАРХИЯ(<СписокЗначений>)

Пример за употреба:

4. Дизайн ПОДОБЕН- Тази функция ни позволява да сравним низ с модел на низ.

Синтаксис: КАТО "<ТекстШаблона>"

Опции за модел на редове:

% - последователност, съдържаща произволен брой произволни символи.

Един произволен знак.

[...] - всеки отделен знак или последователност от знаци, изброени в квадратни скоби. Изброяването може да указва диапазони, например a-z, което означава произволен знак, включен в диапазона, включително краищата на диапазона.

[^...] - всеки отделен знак или последователност от знаци, изброени в квадратни скоби, с изключение на тези, изброени след знака за отрицание.

Пример за употреба:

5. Дизайнът е РАЗРЕШЕН- този оператор ви позволява да изберете само онези записи от базата данни, за които повикващият има разрешение за четене. Тези права се конфигурират на ниво запис (RLS).

Синтаксис: ALLOWED се пише след ключовата дума SELECT

Пример за употреба:

Request.Text = "ИЗБЕРЕТЕ РАЗРЕШЕНИ | Контрагенти. Връзка | ОТ | Директория. Контрагенти КАТО Контрагенти";

6. Дизайн РАЗЛИЧНИ- позволява ви да изберете записи, в които няма дублиращи се записи.

Синтаксис: VARIOUS се пише след ключовата дума SELECT

Пример за употреба:

Request.Text = //избира записи, за които читателят има права "SELECT VARIOUS | Counterparties.Name |FROM | Directory. Counterparties AS Counterparties" ;

Също така конструкцията VARIOUS може да се използва с оператора ALLOWED и други оператори.

Пример за употреба:

Request.Text = //избира различни записи, за които читателят има права "ИЗБЕРЕТЕ РАЗРЕШЕНИ РАЗЛИЧНИ | Контрагенти.Име |ОТ | Директория. Контрагенти КАТО Контрагенти";

7. Дизайн ПЪРВО- избира броя на записите, посочени в параметъра от резултата от заявката.

Синтаксис: FIRST<число>

Пример за употреба:

Request.Text = //изберете първите 4 CCD номера от директорията "SELECT FIRST 4 | CCD Numbers. Link | FROM | Directory. CCD Numbers AS CCD Numbers";

8. Дизайн ЗА ПРОМЯНА- позволява ви да заключите таблица, работи само в транзакции (важи само за автоматични заключвания).

Синтаксис: ЗА СМЯНА<НаименованиеТаблицы>

Пример за употреба:

9. Дизайн ПОРЪЧАЙ ПО- организира данни по конкретно поле. Ако полето е връзка, тогава при задаване на флага АВТОМАТИЧНА ПОРЪЧКАСортирането ще се извърши по представяне на връзката; ако флагът е изключен, тогава връзките се сортират по старшинството на адреса на връзката в паметта.

Синтаксис: СОРТИРАНЕ ПО<НаименованиеПоля>АВТОМАТИЧНА ПОРЪЧКА

Пример за употреба:

10. Дизайн GROUP BY- използва се за групиране на низове на заявки по конкретни полета. Числовите полета трябва да се използват с всяка агрегатна функция.

Синтаксис: ГРУПИРАЙ ПО<НаименованиеПоля1>, .... , <НаименованиеПоляN>

Пример за употреба:

11. Дизайн HAVING- ви позволява да приложите агрегатна функция към условие за избор на данни, подобно на конструкцията WHERE.

Синтаксис: ИМАЩ<агрегатная функция с условием>

Пример за употреба:

12. Строителство ИНДЕКС ПО- използва се за индексиране на полето за заявка. Изпълнението на заявка с индексиране отнема повече време, но ускорява търсенето в индексираните полета. Може да се използва само във виртуални таблици.

Синтаксис: ИНДЕКС ПО<Поле1, ... , ПолеN>

Пример за употреба:

13. Дизайн КЪДЕ- позволява ви да наложите условие за всякакви полета за избор. Резултатът ще включва само записи, които отговарят на условието.

Синтаксис: КЪДЕТО<Условие1 ОператорЛогСоединения УсловиеN>

Пример за употреба:

Query.Text = //всички записи с CompensationRemaining са избрани<>0 и //AmountForCalcCompRemaining > 100 "SELECT | CompensationRPORemains.Counterparty, |CompensationRPORemains.Child, | CompensationRPORemains.CompensationRemaining, | CompensationRPORemains.AmountForCalcCompRemains |Place DataTz |FROM | Регистър на натрупване.CompensationRP.Remains AS Compens ationRPORemains |WHERE |CompensationRPORemaining.CompensationRemaining<>0 | И CompensationRPORemains.AmountForCalcCompRemaining> 100" ;

14. Дизайн РЕЗУЛТАТИ... ОБЩИ- използва се за изчисляване на сумите; дизайнът определя полетата, по които ще се изчисляват сумите и обобщените функции, приложени към полетата за суми. Когато използвате общи суми за всяко поле след конструкцията TOTAL, данните се групират. Има незадължителна конструкция GENERAL, нейното използване също осигурява допълнително групиране. По-долу ще видите пример за резултат от заявката.

Синтаксис: РЕЗУЛТАТИ<АгрегатнаяФункция1, ... , АгрегатнаяФункцияN>ОТ<ОБЩИЕ> <Поле1, ... , ПолеN>

Пример за употреба:

Фигурата очертава групировките, които са били формирани по време на изпълнение на заявката, като най-горната се отнася за раздела GENERAL, а втората за полето Counterparty AgreementAgreement Type.

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

Създайте заявка

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

//Създаване на заявка
Заявка = нова заявка;

//Попълнете текста на заявката
Заявка. Текст= „Тук пишем текста на искането“;

//Предаване на параметри към заявката
Заявка. SetParameter("ParameterName" , ParameterValue) ;

//Изпълнете заявката
Резултат = Заявка. Run() ;

//Качете резултата от заявката към селекцията
Проба = Резултат. Избирам() ;

//Качете резултата от заявката в таблицата със стойности
Таблица = Резултат. Unload() ;

//Последните действия могат да се комбинират
Fetch = Заявка. Run() . Избирам() ;
//или
Таблица = Заявка. Run() . Unload() ;

Основи на езика за заявки 1C

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

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

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

Например, ако трябва да получите стойностите на всички подробности за директорията Контрагенти, тогава заявката ще изглежда така:

Заявка. Текст = "ИЗБИРАМ
| *
| ОТ
| Справочник на контрагентите“.;

Ако трябва да получите само отделни подробности, направете следното:

Заявка. Текст = "ИЗБИРАМ
| код,
| Име,
| Родител
| ОТ
| Справочник на контрагентите“.;

За да получите такова искане, изпратете съобщение в Конструктор на заявкитрябва да изберете съответните полета в раздела Таблици и полета.

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

Заявка. Текст = "ИЗБИРАМ
| Клиенти.Код AS Номер,

| 1000 AS FieldWithValue
| ОТ
;

Fetch = Заявка. Run() . Избирам() ;

Чао Избор. Цикъл Next().
ClientNumber = Проба. Брой;
ClientName = Избор. име;
Стойност = Проба. FieldWithValue;
Краен цикъл;

Използвайте раздела, за да зададете псевдоними Съюзи/Псевдоними V Създател на заявки.

В раздела ръчно се създава поле с фиксирана или изчислена стойност Таблици и полета, в колона Полета.

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

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

Редът се задава в раздела Поръчка V Създател на заявкиброят на избраните елементи, разделителната способност и параметрите за повторяемост са в раздела Допълнително.

Следва продължение…

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

проблем: В някои случаи резултатът от ограниченията за достъп до данни в 1C 8.3 може да зависи от плана за заявка на СУБД. Тази статия разглежда възможните ситуации и дава препоръки как да избегнете това.

Проблемът с възможната зависимост на резултата от ограниченията за достъп до данни от плана за заявка на СУБД може да възникне при изпълнение на заявка за база данни без ключова дума ПОЗВОЛЕН, ако текущият потребител има ограничения за достъп до данни и заявката съдържа едно или повече сравнения на формата:

<Выражение над полями>(В|НЕ В) (<Вложенный запрос>)
(<Выражение над полями 1>, …, <Выражение над полями N>) (В|НЕ В) (<Вложенный запрос>)

Ако в този случай < > (заявка в заявка) използва таблици от база данни, на които са наложени ограничения за достъп, възможно е на някои СУБД заявката да бъде изпълнена успешно, докато на други ще бъде издадено съобщение, при условие че данните в информационните бази са напълно идентични .

Вземете безплатно 267 видео урока за 1C:

Причина за различията

Възможната разлика в поведението се дължи на прилагането на ограничения за достъп до данни без ключова дума ПОЗВОЛЕНв 1C Enterprise 8.3.

Заявка без ключова дума ПОЗВОЛЕНще се изпълни успешно само ако по време на изпълнението му не се получи достъп до забранени данни. За целта се добавя специално сигнално поле, което приема стойността Вярноза тези записи, във формирането на които са участвали само разрешени данни, и стойността лъжаза всички останали записи. Ако поне един примерен запис съдържа стойността лъжав полето за сигнал, изпълнението на заявката завършва необичайно.

Същото сигнално поле се добавя към резултатите от заявките, вложени в сравнението IN/НЕ В. Освен това проверката на стойността на сигналната колона в този случай се извършва с помощта на инструменти на СУБД. По този начин, ако по време на изпълнението на вложена заявка е осъществен достъп до забранени данни, тогава заявката трябва да се провали с грешка Потребителят няма достатъчно права за извършване на операция в базата данни.

Въпреки това, когато се изгражда план за заявка, СУБД може да не получи пълната проба <Вложенным запросом> , и получават само тези записи, които действително са необходими за проверка на условието IN/НЕ В. В този случай заявката може да бъде успешна дори ако <Вложенного запроса> като независимо искане може да възникне достъп до забранени данни.

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

Таблица.Индивидуално КАТО Индивидуално

ще се изпълни с грешка поради опит за достъп до забранени данни. Ако тази заявка е включена в сравнение, например:

Таблица.Индивидуално КАТО Индивидуално

Директория.Индивидуални AS Таблица)

тогава, в зависимост от избрания план за заявка на СУБД, заявката може да бъде изпълнена или успешно, или с грешка. Това поведение на заявката не е грешка, защото забранените данни може или не могат да бъдат достъпни по време на изпълнение на заявката. За да се получи по-предвидим резултат, е необходимо да се конструира заявка по такъв начин, че вложената заявка да гарантира, че няма достъп до очевидно ненужни данни. По-специално, ако предишната заявка е пренаписана така:

Договор за извършване на работа с Физическо лице.Служител.Физическо лице

Документ за извършване на работа с физическо лице КАТО договор за извършване на работа с физическо лице.

Споразумение за извършване на работа с Физическо лице.Служител.Физическо лице B (

Таблица.Индивидуално КАТО Индивидуално

Справочник.Индивидуални лица AS Таблица