Обмеження доступу до даних в ролях 1с. Використання RLS

Конструктор обмежень дозволяє скласти обмеження доступу на рівні записів і полів бази даних. Список обмежень доступний з контекстного меню гілки Ролі дерева конфігурації; конструктор викликається при додаванні нового обмеження (кнопка далі) Або редагуванні існуючого:

Для виклику конструктора при створенні нового обмеження натискаємо кнопку Конструктор запиту:

Мова конструювання обмежень схожий на мову запитів, конструктор відповідно теж. У ньому можна визначити одну або кілька пов'язаних таблиць, за якими будуть задаватися обмеження:

Саме обмеження також формулюється у вигляді тексту запиту:

Питання 04.51 іспиту 1С: Професіонал по платформі. У конструкторі обмежень доступу до даних:

Можна використовувати тільки поля об'єкта, для якого визначається обмеження
Можна використовувати тільки поля об'єкта, для якого визначається обмеження і поля вкладених таблиць (по відношенню до полів об'єкта)
Будь-які таблиці, які в запиті можна пов'язати з полями об'єкта, для якого визначається обмеження

Правильна відповідь третій. Якщо в конструкторі задано кілька таблиць з даними, то в ньому з'являється закладка Зв'язки:

В якій і можна прописати обмеження, пов'язані з іншими таблицями:

Питання 04.52 іспиту 1С: Професіонал по платформі. При визначенні обмеження доступу в конструкторі обмежень доступу до даних ...

текст запиту може бути сформований тільки самим конструктором
текст запиту може бути введений тільки вручну
текст запиту може бути сформований як самим конструктором, так і вручну

Правильна відповідь третій - можна конструктором, можна вручну.

Питання 04.53 іспиту 1С: Професіонал по платформі. При визначенні обмеження доступу в конструкторі обмежень доступу до даних:

Правило обмеження визначається тільки на закладці "Зв'язки"
Правило обмеження визначається тільки на закладці "Умови"
Налаштування, виконані на обох закладках конструктора, беруть участь у визначенні умови на доступ до даних

Правильна відповідь третій, потрібні обидві закладки, інакше навіщо вони.

Питання 04.54 іспиту 1С: Професіонал по платформі. При визначенні обмеження доступу в конструкторі обмежень доступу до даних текст умови:

Починається з ключового слова "Вибрати"
Починається тільки з конструкції "Вибрати Різні"
Починається тільки з конструкції "Вибрати Дозволені"
Ключове слово "Вибрати" не визначається
Допустимі варіанти 1 і 3

Правильна відповідь четвертий - на відміну від мови запитів, слова Вибрати тут немає.

Питання 07.01 іспиту 1С: Професіонал по платформі. Під час налаштування обмеження доступу до даних допускається установка декількох (по числу полів) обмежень:

Для права "Читання"
Для права "Зміна"
Для права "Додавання"
Для права "Видалення"
Для всіх перерахованих вище прав
Для всіх можливих прав

Починаючи з платформи 8.0 системи 1С Підприємство, існує можливість обмежувати права доступу користувачів на рівні записів. Для цього використовується механізм RLS (Record Level Security). Така «тонка» налаштування може бути корисна для обмеження доступу по організаціям, клієнтам, номенклатурі і ін.

RLS - це можливість розробника задати умову на таблиці бази даних для тих чи інших користувачів (груп користувачів) і не дати їм побачити зайвого. Умова має булевий тип. Якщо значення умови приймає значення «істина», то доступ надається, в іншому випадку - забороняється.

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

RLS застосовується для наступних видів прав доступу:
* Читання
* Додавання
* Зміна
* Видалення

Порядок настройки RLS

Розглянемо простий приклад встановлення. Знімки екрану зроблені на версії 1С Підприємство 8.2 (8.2.9.356). Синтаксис шаблонів текстів обмежень описаний в документації по 8.2 в книзі «Керівництво розробника. Частина 1 », тому на ньому зупинятися не будемо.

Отже, насамперед потрібно визначити шаблони обмежень для кожної існуючої ролі.

Після цього на підставі зазначених шаблонів задаються обмеження до необхідних об'єктів. Для редагування тексту умови можна скористатися конструктором обмежень доступу до даних.

Для редагування кількох ролей зручно управляти через вікно «Все ролі».

Для копіювання умов в інші ролі можна використовувати вікно «Все обмеження доступу». Шаблони в інші ролі можна буде скопіювати лише вручну.

От і все. Можна перевірити результат.

Недоліки використання RLS:
1. Застосування механізму обмеження доступу на рівні записів призводить до неявному збільшення таблиць, що беруть участь в запиті, що може привести до помилок в клієнт-серверному режимі роботи бази даних.
2. Для контролю запису буває важко або неможливо реалізувати складну логіку програми. У таких випадках краще використовувати умови в процедурі ПріЗапісі ().
3. Написання умови (запиту) вимагає певної кваліфікації розробника.
4. Додаткові труднощі може створити неможливість налагодження умови (запиту).

У типових конфігураціях права на рівні записів можуть бути задані інтерактивно для наступних об'єктів: організації, контрагенти, номенклатура, склади, підрозділи, фізичні особи, заявки кандидатів і інші.

Слід пам'ятати, що обмеження прав доступу на рівні записів досить ресурсномісткий механізм і чим складніші обмеження Ви поставите, тим повільніше програма буде працювати, особливо при великій базі даних.
Мелкоступов Олександр

Інформація взята з сайту

В системі 1С Підприємство 8, сьогодні ми продовжимо вивчення механізму прав і заглибимося далі - в механізм RLS (обмеження прав на рівні записів).

Нижче ми розглянемо переваги і недоліки даного методу і розглянемо настройку RLS в 1С Підприємстві 8.3 на прикладі.

1С RLS (Record Level Security) або обмеження прав на рівні запису - це прав користувачів в системі 1С, яка дозволяє розділити права для користувачів в розрізі динамічно мінливих даних.

Найпоширеніший вид настройки 1C RLS - обмеження видимості користувача в розрізі організацій або клієнтів (користувач бачить лише «свої» дані).

Основна перевага - наявність механізму взагалі, механізм досить складний і цікавий. Дозволяє дуже тонко розмежувати права користувачів - користувачі можуть навіть не здогадуватися про існування в системі інших даних.

Недоліки 1С 8 RLS

Серед недоліків можна відзначити помітне падіння продуктивності системи. Це викликано тим, що платформа при побудові запиту в базі даних ускладнює будь-який запит розробника додатковими умовами.

Також серед недоліків - складність настройки цього функціоналу та складність налагодження. 1C випустило дуже мало матеріалів по налаштуванню і роботі цього функціоналу. Досить важко знайти фахівця, який грамотно налаштував би механізм.

Налаштування обмеження прав на рівні записів 1С RLS

Обмеження прав на рівні запису (RLS) застосовується для обмеження наступних типів прав:

читання
Додавання
зміна
видалення

Отримайте 267 відеоуроків по 1С безкоштовно:

Зовні настройка RLS (прав на рівні записів) схожа на складання простого. Приклад шаблону для обмеження доступу видимості документів по клієнту з шапки документа:

## Якщо & ІспользоватьОграніченіяПравДоступаНаУровнеЗапісей ## Тоді

ТекущаяТабліца ІЗ # ТекущаяТабліца ЯК ТекущаяТабліца
ЛІВЕ З'ЄДНАННЯ (ВИБРАТИ РІЗНІ
СоставГруппи.Ссилка ЯК ГруппаПользователей
З
Справочнік.ГруппиПользователей.ПользователіГруппи ЯК СоставГруппи
ДЕ
СоставГруппи.Пользователь \u003d & ТекущійПользователь) ЯК ГруппиПользователей
ПО (& ІспользоватьОграніченіяПравДоступаНаУровнеЗапісей)
ДЕ (& ІспользоватьОграніченіяПравДоступаНаУровнеЗапісей \u003d БРЕХНЯ
АБО (НЕ 1 В
(ВИБРАТИ ПЕРШІ 1
1 ЯК ПолеОтбора
З
РегістрСведеній.НазначеніеВідовОб'ектовДоступа ЯК НазначеніеВідовОб'ектовДоступа
ДЕ
НазначеніеВідовОб'ектовДоступа.ГруппаПользователей \u003d ГруппиПользователей.ГруппаПользователей
І ВИБІР
КОЛИ НазначеніеВідовОб'ектовДоступа.ВідОб'ектаДоступа \u003d ЗНАЧЕННЯ (Перечісленіе.ВідиОб'ектовДоступа.Контрагенти)
І ТекущаяТабліца. # Параметр (1) ПОСИЛАННЯ Справочнік.Контрагенти
І НЕ ТекущаяТабліца. # Параметр (1) \u003d ЗНАЧЕННЯ (Справочнік.Контрагенти.ПустаяСсилка)
ТОДІ ВИБІР
КОЛИ 1 В
(ВИБРАТИ ПЕРШІ 1
1
З
Справочнік.Контрагенти ЯК Контрагенти ВНУТРІШНЄ З'ЄДНАННЯ РегістрСведеній.НастройкіПравДоступаПользователей ЯК НастройкіПравДоступаПользователей
ПО
НастройкіПравДоступаПользователей.Об'ектДоступа \u003d Контрагенти.ГруппаДоступаККонтрагенту
І НастройкіПравДоступаПользователей.ВідОб'ектаДоступа \u003d ЗНАЧЕННЯ (Перечісленіе.ВідиОб'ектовДоступа.Контрагенти)
І (НастройкіПравДоступаПользователей.Пользователь \u003d НазначеніеВідовОб'ектовДоступа.ГруппаПользователей
АБО НастройкіПравДоступаПользователей.Пользователь \u003d ЗНАЧЕННЯ (Справочнік.ГруппиПользователей.ВсеПользователі))
І НастройкіПравДоступаПользователей.Запісь \u003d ІСТИНА
ДЕ
Контрагенти.Ссилка \u003d ТекущаяТабліца. # Параметр (1))
ТОДІ ІСТИНА
ІНАКШЕ БРЕХНЯ
КІНЕЦЬ
ІНАКШЕ ІСТИНА
КІНЕЦЬ \u003d БРЕХНЯ))
І НЕ ГруппиПользователей.ГруппаПользователей Є NULL)
## КонецЕсли

По суті, цей запит кожен раз додається при запиті до таблиці «# ТекущаяТабліца». З чого можна уявити, яку додаткове навантаження несе в собі механізм обмеження на рівні запису.

Як Ви бачите, в запиті є спеціальні параметри, наприклад »& ІспользоватьОграніченіяПравДоступаНаУровнеЗапісей». Це параметри в РЛС підбираються з об'єктів метаданих - ««. Як правило, вони задаються при старті сесії користувача.

Конструктор обмеження доступу до даних

Для зручності розробника в 1С 8.3 є спеціальна утиліта для допомоги в налаштування РЛС - Конструктор обмеження доступу до даних. Він викликається з поля «Обмеження доступу». Виглядає наступним чином:

Об'єкт конфігурації «роль» дає набір прав на операції (дії) над об'єктами конфігурації.

Роль «Повні права».

Це всього лише роль (не визначеного), в якій встановлені прапорці на всі види прав на всі об'єкти конфігурації.

Відмінність її від інших ролей - наявність права «Адміністрування».

У разі створення хоча б одного користувача, система починає перевіряти наявність права «Адміністрування» - воно повинно бути мінімум в одного користувача.

Обмеження доступу на рівні записів

Row Level Security (RLS) - обмеження на рівні записів.

Механізм обмежень доступу до даних дозволяє управляти правами доступу не тільки на рівні об'єктів метаданих, а й на рівні об'єктів бази даних. Для обмеження доступу до даних можуть бути використані наступні об'єкти:

ролі,
параметри сеансу,
функціональні опції,
привілейовані загальні модулі,
ключове слово ДОЗВОЛЕНІ в мові запитів.

Механізм призначений для обмеження доступу до записів таблиці об'єктів метаданих по довільним умов, що накладаються на значення полів рядків цих таблиць. Наприклад, щоб бачити записи тільки по «своїм» контрагентам, організаціям і т.д.

Технічна реалізація обмежень доступу в 1С

1С формує запит до СУБД. Кластер серверів додає до запиту секцію ДЕ, в якій міститься текст умови на обмеження доступу по RLS, потім цей запит відправляється в СУБД, витягнуті дані повертаються на клієнт 1С.

Такий механізм буде працювати при будь-який запит з клієнта:

в звітах,
в динамічних списках і в звичайних формах списків
в довільних запитах.

Подібна реалізація механізму сильно впливає на продуктивність.

Шляхи обходу обмежень доступу.

У великих ресурсномістких операціях (обробки перепроведення документів, наприклад) частина коду можна виносити в привілейовані модулі.

А) привілейований модуль - це загальний модуль з прапором «Привілейований» у властивостях.

Його особливість полягає в тому, що код в ньому виповнюється без будь-якого контролю прав доступу, в тому числі і RLS.

Б) Також привілейований режим можна включити для модулів об'єктів документів. Це робиться у властивостях документа, прапор

Привілейований режим при проведенні
Привілейований режим при скасуванні проведення

В) Метод УстановітьПрівілегірованнийРежім ()

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

З наступного рядка коду буде діяти привілейований режим виконання.

Діяти він буде до рядка відключення цього режиму або до кінця процедури / функції

(Істина);

// будь-який код тут буде виконаний без контролю прав і RLS

УстановітьПрівілегірованнийРежім(Брехня); // або кінець процедури / функції

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

Якщо в процедурі або функції викликів методу УстановітьПрівілегірованнийРежім(Брехня) зроблено більше, ніж викликів методу УстановітьПрівілегірованнийРежім(Істина), то буде викликано виключення

функція ПрівілегірованнийРежім() Повертає Істина, якщо привілейований режим ще включений, і Брехня, якщо він повністю виключений. При цьому не аналізується кількість установок привілейованого режиму в конкретній функції.

Всі викликані процедури і функції також будуть виконуватися в привілейованому режимі.

Також існує можливість стартувати привілейований сеанс. Це сеанс, в якому привілейований режим встановлений з самого початку роботи системи. При цьому під час роботи метод ПрівілегірованнийРежім() Буде завжди повертати Істина, а можливість відключити привілейований режим не підтримується. Стартувати привілейований сеанс може тільки користувач, якому доступні адміністративні права (право Адміністрування). Почніть розмову можна виконати за допомогою ключа командного рядка запуску клієнтської програми UsePrivilegedMode або параметра рядка з'єднання з інформаційною базою prmod.

Закономірно виникає питання: Навіщо тоді взагалі налаштовувати обмеження доступу, якщо його можна так легко обійти?

Безпечний режим.

Так, можна написати зовнішню обробку з привілейованим режимом виконання і вивантажити / зіпсувати дані. Для запобігання цьому в системі є метод глобального контексту

УстановітьБезопаснийРежім().

Безпечний режим крім іншого ігнорує привілейований режим.

Його потрібно встановлювати перед програмним викликом зовнішніх обробок або експортних процедур і функцій з їх модулів.

При виконанні заборонених операцій під час виконання генерує виняток.

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

Налаштування обмеження доступу

RLS можна налаштувати тільки для прав:

читання (select)
додавання (insert)
зміна (update)
видалення (delete)

Для операцій читання і видалення об'єкт, що знаходиться в базі даних, повинен відповідати обмеження доступу до даних.

Для операції додавання обмеження доступу до даних повинен відповідати об'єкт, який планується записати в базу даних.

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

Для всіх інших прав такої можливості немає.

Додамо нове обмеження для права «читання» довідника «Номенклатура». Відкриється список полів, для яких можна налаштувати додається обмеження.

Це означає, що при спробі отримати доступ до зазначених прапорцями полях, обмеження спрацює, а при спробі отримати доступ до невідміченим полях обмеження не спрацює.

Якщо вибрати прапор « Інші поля», Обмеження буде налаштоване для всіх полів таблиці, крім полів, для яких обмеження задані явно.

* Особливість: для прав додавання, зміна, видалення:

Обмеження може бути налаштоване тільки для всіх полів.

Обмеження може бути тільки одне.

Для права «Читання» можна налаштувати декілька умов, вони будуть об'єднуватися логічним оператором «І».

В обмеженнях на об'єкти бази даних наступних типів можуть бути використані не всі поля основного об'єкта даних обмеження:

в регістрах накопичення обмеження доступу можуть містити тільки вимірювання основного об'єкта обмеження;
в регістрах бухгалтерії в обмеженнях можна використовувати тільки балансові вимірювання основного об'єкта обмеження

Якщо в умовах обмеження доступу до даних оборотного регістра накопичення використовуються вимірювання, що не входять в підсумки, то при зверненні до віртуальної таблиці оборотів не використовуються збережені підсумки і запит виконується повністю по таблиці рухів.

Механізм накладення обмежень доступу.

Будь-яка операція над даними, збереженими в базі даних, в «1С: Підприємство» в кінцевому рахунку призводить до звернення до бази даних з деяким запитом на читання або зміна даних. В процесі виконання запитів до бази даних внутрішні механізми «1С: Підприємства» виконують накладення обмежень доступу. При цьому:

Формується список прав (Читання, додавання, зміна, видалення), список таблиць бази даних і список полів, які використовуються цим запитом.
З усіх ролей поточного користувача вибираються обмеження доступу до даних для всіх прав, таблиць і полів, задіяних в запиті. При цьому якщо якась роль не містить обмежень доступу до даних який-небудь таблиці або поля, то це означає, що в даній таблиці доступні значення необхідних полів з будь-якого запису. Інакше кажучи, відсутність обмеження доступу до даних означає наявність обмеження ДЕ Істина.
Виходять поточні значення всіх параметрів сеансу і функціональних опцій, Що беруть участь в обраних обмеженнях.

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

Обмеження, отримані з однієї ролі, об'єднуються операцією І.

Обмеження, отримані з різних ролей, об'єднуються операцією АБО.

Побудовані умови додаються до SQL-запитах, з якими «1С: Підприємство» звертається до СУБД. При зверненні до даних з боку умов обмеження доступу перевірка прав не виконується (ні до об'єктів метаданих, ні до об'єктів бази даних). Причому механізм додавання умов залежить від обраного способу дії обмежень «все» або «дозволені».

* Особливість: Якщо користувачеві доступні кілька ролей з налаштованими обмеженнями на рівні записів до одного об'єкту, то в цьому випадку умови обмежень складаються логічною операцією «АБО». Іншими словами повноваження користувача складаються.

Звідси випливає слід висновок: не допускати перетину умови обмеження доступу до одного об'єкту в різних ролях, т.к в цьому випадку сильно ускладниться текст запиту і це вплине на продуктивність.

Спосіб «Все».

При накладенні обмежень способом «все» до SQL-запитах додаються умови і поля так, щоб «1С: Підприємство» могло отримати інформацію про те, чи були в процесі виконання запиту до бази даних використані дані, заборонені для даного користувача чи ні. Якщо заборонені дані були використані, то ініціюється аварійне завершення запиту через порушення прав доступу.

Накладення обмежень доступу способом «все» схематично представлено на малюнку:

Спосіб «Дозволені».

При накладенні обмежень способом «дозволені» до SQL-запитах додаються такі умови, щоб заборонені активного користувача записи не чинили впливу на результат запиту. Інакше кажучи, при накладенні обмежень в режимі «дозволені» заборонені даному користувачеві записи вважаються відсутніми і на результат операції не впливають, що схематично представлено на малюнку:

Обмеження доступу до даних накладаються на об'єкти бази даних в момент звернення «1С: Підприємства» до бази даних.

У клієнт-серверному варіанті «1С: Підприємства» накладення обмежень виконується на сервері «1С: Підприємства».

Однак ця опція (ДОЗВОЛЕНІ) не спрацює у разі, якщо ми в запиті звернемося до таблиці, для якої не налаштовані обмеження доступу, але в якій є посилання на рядки таблиці з налаштованими обмеженнями. В цьому випадку результат запиту видасть «<Объект не найден>... ... »замість значення посилального поля.

Якщо ви розробляєте звіт або обробку з використанням запитів типовий або самопісний конфігурації, завжди ставте прапор "Дозволені», Щоб звіт працював під будь-яким користувачем з будь-яким набором прав.

У разі об'єктного читання даних з бази немає можливості поставити прапор "Дозволені». Тому потрібно налаштовувати відбори для об'єктного читання з урахуванням можливих обмежень прав доступу для користувача. Засобів отримання тільки дозволених даних в об'єктній техніці не передбачено.

Важливо, що якщо в запиті не вказано ключове слово ДОЗВОЛЕНІ, то все відбори, задані в цьому запиті, не повинні суперечити жодному з обмежень на читання об'єктів бази даних, що використовуються в запиті. При цьому якщо в запиті використовуються віртуальні таблиці, то відповідні відбори повинні бути накладені і на самі віртуальні таблиці.

Практика 1. Конструктор запитів в налаштуваннях RLS.

Складемо текст секції «ДЕ» в запиті до довідника. Можна скористатися конструктором запитів.
Конструктор має урізаний вид.

Закладка «Таблиці»

Основна таблиця буде таблицею об'єкта, для якого налаштовується обмеження.

Можна також вибирати і інші таблиці і налаштовувати між ними різні зв'язку на закладці «Зв'язки».

Закладка «Умови»

Тут налаштовуються власне умови обмеження доступу

Додамо умови на реквізит «Ціна» довідника номенклатура для права на «читання» до всіх полів таблиці.

«Номенклатура ДЕ Номенклатура.Цена\u003e 500»

Перевіримо, як спрацює це просте правило. Таблиця довідника містить такі елементи:

Після настройки обмеження доступу таблиця покаже тільки елементи, що задовольняють умові:

Пропали також і групи. Змінимо текст обмеження

«Номенклатура ДЕ Номенклатура.Цена\u003e 500

АБО Номенклатура.ЕтоГруппа »

Ну ось тепер те, що потрібно.

Якщо в налаштуванні списку прибрати відображення поля «код», будуть виведені всі елементи довідника, тобто обмеження не спрацювало. Якщо поставити відображення поля «Код», обмеження буде працювати.

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

Якщо спробувати отримати «обмежений» реквізит програмним чином, також буде викликана помилка доступу.

Більш того, не можна буде звернутися до будь-яких полях об'єкта через посилання, т.к при отриманні посилання система зчитує весь об'єкт цілком, і якщо в ньому є «обмежені» реквізити, об'єкт лічений не буде.

Тому при програмній роботі з об'єктами БД потрібно мати на увазі можливі обмеження на рівні записів і отримувати всі необхідні дані об'єкта запитом і потім поміщати їх в структуру або виконувати частину коду в привілейованому модулі.

Після настройки обмеження доступу змінилося відображення рядка в списку прав - вона стала сірою і з'явилася піктограма.

Обмеження при налаштуванні доступу (RLS).

Немає секції Підсумки;
Не можна звертатися до віртуальних таблиць регістрів;
В явному вигляді не можна використовувати параметри;
У вкладених запитах можуть використовуватися будь-які\u003e / span\u003e засоби мови запитів, крім:
- оператора В ІЄРАРХІЇ;
- пропозиції ПІДСУМКИ;
- результати вкладених запитів не повинні містити табличні частини\u003e / span\u003e;
- віртуальних таблиць, Зокрема ОстаткіІОбороти

Практика 2. Номенклатура з актуальною ціною.

Зробити обмеження доступу, якщо потрібно виводити номенклатуру з актуальною ціною більше певного значення, наприклад, 100.

Рішення:

Додаємо нове правило обмеження доступу для довідника «Номенклатура» на право «читання».
Вибираємо «інші поля».
У конструкторі додаємо вкладений запит. У ньому вибираємо таблицю регістра відомостей «Ціни номенклатури».
Виберіть «порядок» немає - це особливість конструктора запитів для побудови запиту обмеження доступу.
На вкладці «Додатково» ставимо «перші 999999999», вкладка «порядок» з'явилася.
Налаштовуємо упорядкування по полю «Період» по спадаючій.
Потім налаштовуємо зв'язок основної таблиці з вкладеним запитом за посиланням.

Шаблони обмежень доступу.

Практика 3. Обмеження на «контрагенти» за значенням в константі.

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

Крім цього, потрібно налаштувати обмеження і для всіх об'єктів, що використовують довідник «Контрагенти» в реквізитах.

Рішення

Для довідника «Контрагенти» для права «читання» налаштуємо обмеження, додавши в секцію «Умови» вкладений запит до константи. Не забути ЕтоГруппа.

Бачимо проблему, довідник Контрагенти фільтрується вірно, а документи з реквізитом «Контрагент» відображаються всі, деякі з «битими» посиланнями в реквізиті «Контрагент».

Тепер потрібно налаштувати обмеження доступу для всіх об'єктів, що використовують посилання на «Контрагенти». Знайдемо їх сервісом «пошук посилань на об'єкт».

Скопіюємо і трохи доопрацюємо текст умови RLS з довідника «Контрагенти». Це потрібно зробити стільки раз, скільки знайдено об'єктів.

Або використовувати шаблон обмежень доступу, щоб уникнути проблем дублювання коду.

Шаблони обмежень доступу налаштовуються на рівні ролі і можуть використовуватися для будь-якого об'єкта в рамках редагованої ролі.

Можна винести в шаблон будь-який шматок тексту обмеження доступу. Виклик шаблону здійснюється через символ «#». Наприклад, # ШаблонКонтрагент.

Через # в 1С пишуться інструкції препроцесору. У контексті виконання налаштувань обмежень доступу платформа замінює текст виклику шаблону на текст шаблону.

Винесемо в шаблон «ШаблонКонтрагент» текст після слова ДЕ, крім тексту про ЕтоГруппа.

Параметри в шаблонах обмежень доступу.

Продовжимо рішення задачі 2.

Проблема полягає тепер у тому, що основна таблиця в довіднику називається «контрагент», в документі «Прибуткова накладна». Проверяемое поле в довіднику називається «посилання», в документі - «Контрагент».

Змінимо в тексті шаблону назва основної таблиці на «# ТекущаяТабліца»

«# ТекущаяТабліца» - це зумовлений параметр.

І через точку вкажемо номер вхідного параметра - «. # Параметр (1)

«# Параметр» - це теж зумовлене значення. Може містити будь-яку кількість вхідних параметрів. Звернення до них відбувається за порядковим номером.

У тексті обмеження доступу для довідника зазначимо таке:

Для документа наступне:

«РеалізаціяТоваров ДЕ # ШаблонКонтрагент (« Контрагент »)»

При виклику шаблону обмеження доступу параметри в нього передавати потрібно тільки як Рядок, тобто в лапках.

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

Текст шаблону такий:

# ТекущаяТабліца ДЕ # ТекущаяТабліца. # Параметр (1) \u003d # Параметр (2)

Текст шаблону містить частину тексту на мові обмеження доступу до даних і може містити параметри, які виділяються за допомогою символу «#».

Після символу «#» можуть слідувати:

Одне з ключових слів:
- Параметр, після якого в дужках вказується номер параметра в шаблоні;
- ТекущаяТабліца - позначає вставку в текст повного імені таблиці, для якої будується обмеження;
- ІмяТекущейТабліци - позначає вставку в текст повного імені таблиці (як строкове значення, в лапках), до якої застосовується інструкція, на поточному варіанті вбудованого мови;
- ІмяТекущегоПраваДоступа - містить ім'я права, для якого виконується поточне обмеження: ЧИТАННЯ / READ, ДОДАВАННЯ / INSERT, ЗМІНА / UPDATE, ВИДАЛЕННЯ / DELETE;
ім'я параметра шаблона - означає вставку в текст обмеження відповідного параметра шаблона;
символ «#» - позначає вставку в текст одного символу «#».

У вираженні обмеження доступу можуть міститися:

Шаблон обмеження доступу, який вказується в форматі # ІмяШаблона ( «Значення параметра шаблона 1», «Значення параметра шаблона 2», ...). Кожен параметр шаблону полягає в подвійні лапки. При необхідності вказівки в тексті параметра символу подвійної лапки слід використовувати дві подвійні лапки.
Функція СтрСодержіт (ГдеІщем, ЧтоІщем). Функція призначена для пошуку входження рядка ЧтоІщем в рядку ГдеІщем. Повертає Істина в разі, якщо входження виявлено і Брехня - в іншому випадку.
Оператор + для конкатенації рядків.

Для зручності редагування тексту шаблону на закладці Шаблони обмежень у формі ролі потрібно натиснути кнопку Встановити текст шаблону. У діалозі ввести текст шаблона і натиснути кнопку ОК.

Їх не можна встановити методом УстановітьПараметр () або чимось подібним.

Як параметри в даному випадку виступають:

параметри сеансу
функціональні опції

Читання параметрів сеансу в запиті обмеження доступу відбувається в привілейованому режимі, тобто без контролю прав на операції з ними.

Практика 4. Доступ до «своїм» контрагентам

Необхідно налаштувати обмеження доступу поточного користувача до «своїм» контрагентам.

Є довідник «Користувачі», довідник «Контрагенти», документи з реквізитом «Контрагент».

Поточний користувач повинен бачити дані тільки по тим контрагентам, для яких з ним встановлено зв'язок.

Зв'язок теж потрібно налаштувати.

Можливі варіанти:

Встановлення зв'язків користувач + контрагент

Реквізит в довіднику контрагенти
регістр відомостей

Можливі рішення задачі:

Зберігати користувача в константі - поганий варіант, константа доступна всім користувачам.
Зберігати в параметрах сеансу фіксований масив контрагентів поточного користувача - не дуже гарний варіант, Контрагентів може бути багато
Зберігати в параметрах сеансу поточного користувача, потім запитом отримувати список «його» контрагентів - прийнятний варіант.
Інші варіанти.

Рішення.

Створимо новий параметр сеансу «ТекущійПользователь» і пропишемо його заповнення в модулі сеансу.

Створимо регістр відомостей «Відповідність менеджерів і контрагентів»

Створимо нову роль і в ній нове обмеження доступу для документа «ПриходнаяНакладная».

У тексті запиту з'єднаємо основну таблицю з регістром відомостей по Контрагент \u003d Контрагент і Менеджер \u003d & ТекущійПользователь. Вид з'єднання Внутрішнє.

По можливості краще уникати вкладених запитів в текстах обмеження доступу, т.к він буде виконуватися при кожному читанні даних з цього об'єкта з БД.

Перевіряємо - обмеження працюють

* Особливість: Якщо змінити список контрагентів користувача в регістрі обмеження доступу будуть діяти відразу без перезапуску сеансу користувача.

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

Необхідно реалізувати обмеження на редагування даних раніше встановленої дати заборони змін.
Обмежувати потрібно для користувачів.

Створимо регістр відомостей «ДатиЗапретаІзмененій» з вимірюванням Користувач, ресурс ДатаЗапрета.

Побудуємо логіку рішення таким чином:

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

Очевидно, що таке обмеження можна налаштувати для об'єктів бази даних, які мають деяку позицію на осі часу. Це можуть бути

документи
Періодичні регістри відомостей

Створимо нову роль «ОраніченіяПоДатеЗапретаІзмененій».

У ній для документа «ПриходнаяНакладная» для права «зміна» додамо нове обмеження доступу.

Налаштування вказуємо для всіх полів.

Текст обмеження такої:

ПриходнаяНакладная З Документ.ПріходнаяНакладная ЯК ПриходнаяНакладная

ДатиЗапретаІзмененій.ДатаЗапрета ЯК ДатаЗапрета
З

ВНУТРІШНЄ З'ЄДНАННЯ (ВИБРАТИ
МАКСИМУМ (ДатиЗапретаІзмененій.Пользователь) ЯК Користувач
З
РегістрСведеній.ДатиЗапретаІзмененій ЯК ДатиЗапретаІзмененій
ДЕ
(ДатиЗапретаІзмененій.Пользователь \u003d & ТекущійПользователь
АБО ДатиЗапретаІзмененій.Пользователь \u003d ЗНАЧЕННЯ (Справочнік.пользователі.ПустаяСсилка))) ЯК ВЗ_Пользователь
ПО ДатиЗапретаІзмененій.Пользователь \u003d ВЗ_Пользователь.Пользователь) ЯК ВложеннийЗапрос
ПО ПріходнаяНакладная.Дата\u003e ВложеннийЗапрос.ДатаЗапрета

Перевіряємо - обмеження працює.

Використання інструкцій препроцесору

# Якщо Условіе1 # Тоді

Фрагмент запиту 1

# ІначеЕслі Условіе2 # Тоді

Фрагмент запиту 2

# Інакше

Фрагмент запиту 3

# КонецЕсли

В умовах можна використовувати логічні операції (і. Або, не тощо) і звернення до параметрів сеансу.

Такий підхід в контексті побудови обмежень доступу зручний тим, що в залежності від умов буде скомпільовано коротший текст запиту. А більш простий запит менше навантажує систему.

Мінус полягає в тому, що конструктор запиту з таким текстом працювати не буде.

* Особливість:

На відміну від інструкцій препроцесору вбудованої мови в текстах обмеження доступу перед оператором Тоді потрібно ставити грати - # Тоді

Практика 6. Перемикач «Використовувати RLS»

Доповнимо нашу систему обмежень перемикачем, який включає / вимикає використання обмеження на рівні записів.

Для цього додамо Константу і параметр сеансу з ім'ям «ІспользоватьRLS».

Пропишемо в Модулі сеансу установку значення параметра сеансу з значення константи.

Додамо в усі тексти обмеження доступу такий код:

«# Якщо & ІспользоватьRLS # Тоді ... .. # КонецЕсли»

Перевіряємо - все працює.

Однак, тепер після включення прапора «використовувати РЛС» зміни відразу в силу не вступлять. Чому?

Тому що параметр сеансу встановлюється при запуску сеансу.

Можна зробити так, щоб в момент запису нового значення константи перевстановлювати значення параметра сеансу, але це буде працювати тільки для поточного сеансу користувача. Іншим користувачам необхідно видавати повідомлення про необхідність перезапустити систему.

Кінець першої частини.