Як визначається доступ до запису
Існують різні способи отримання доступу до того чи іншого запису в Dataverse. Щоб мати можливість виконати певну дію з таблицею (Створити, Прочитати, Записати, Видалити, Додати, Додати до, Призначити, Поділитися), виконуються дві основні перевірки: перевірка привілеїв і доступу.
Перевірка права
Перевірка привілеїв - це перший бар’єр, який потрібно пройти, щоб зробити певну дію із записом таблиці. При перевірці права підтверджується, що користувач має необхідне право для доступу до відповідної таблиці. Для кожної таблиці, незалежно від того, готової чи настроюваної, є різні права, які надають можливості взаємодії із записами цього типу.
Наприклад, для бізнес-партнера є наведені далі права.
| Право | Опис |
|---|---|
| Творити | Необхідне для створення запису. Тип записів, які можна створювати, залежить від рівня доступу, який надає дозвіл, визначений у ролі безпеки користувача. |
| Читати | Необхідно відкрити запис для перегляду вмісту. Які саме записи можна читати, залежить від рівня дозволу, визначеного в ролі безпеки користувача. |
| Написати | Необхідно для внесення змін до запису. Які саме записи можна змінювати, залежить від рівня дозволу, визначеного в ролі безпеки користувача. |
| Видалити | Необхідно для остаточно видалення запису. Які саме записи можна видалити, залежить від рівня дозволу, визначеного в ролі безпеки користувача. |
| Додати | Необхідно для зв’язавання поточного запису з іншим записом. Наприклад, якщо користувач має для примітки право «Додавання», він може додати примітку до потенційної угоди. Які саме записи можна додавати, залежить від рівня дозволу, визначеного в ролі безпеки користувача. У випадку зв’язків багато-до-багатьох ви повинні мати права на додавання для обох таблиць, які пов’язуються із записом або зв’язок яких із записом скасовується. |
| Додати до | Необхідно для зв’язування запису з поточним записом. Наприклад, можна додати примітку до потенційної угоди, якщо користувач має для цієї потенційної угоди право на додавання. Які саме записи можна додавати, залежить від рівня доступу, який надає дозвіл, визначений у ролі безпеки користувача. |
| Призначати | Необхідно для покладання відповідальність за запис на іншого користувача. Які саме записи можна призначати, залежить від рівня дозволу, визначеного в ролі безпеки користувача. |
| Ділити | Необхідно для отримання доступу до записів на іншого користувача зі збереженням власних прав доступу. Які саме записи можна зробити спільними, залежить від рівня дозволу, визначеного в ролі безпеки користувача. |
Щоб виконати дію із записом, користувачу слід безпосередньо призначити необхідне право за допомогою ролі, або він має бути учасником робочої групи, що має роль безпеки, якій призначено це право. Якщо це не так, користувач отримає помилку «В доступі відмовлено» із зазначенням того, що в цього користувача немає необхідного права для виконання відповідної дії.
Наприклад, за сценарієм, де користувач бажає створити запис бізнес-партнера, йому необхідно мати право на створення. Таке право надається способом призначення йому ролі безпеки або призначення ролі безпеки робочій групі, до якої він належить.
Нотатка
При створенні або редагуванні ролі безпеки надається право на цю роль із заданим рівнем доступу. При перевірці права рівень доступу не враховується, але він враховується при перевірці доступу після задовільного виконання перевірки права.
Перевірка доступу
Якщо перевірку права пройдено, виконується перевірка доступу. При перевірці доступу підтверджується, що користувач має необхідні права для виконання дії, яку він намагається виконати.
Є чотири різні способи, якими користувач може мати права доступу для виконання дії в тому або іншому записі. Типи виразів наведено нижче.
- Право власності
- Доступ ролі
- Спільний доступ
- Ієрархічний доступ
Важливо
Усі ці типи доступу перевіряються в процесі перевірки доступу, так що можливо, що користувач матиме доступ для виконання необхідної дії із записом у більш ніж один спосіб.
Право власності
Користувач може мати доступ до того або іншого запису, тому що він відповідає за запис, про який йдеться, або є членом робочої групи, що відповідає за запис, про який йдеться. У обох випадках будь-який рівень доступу є достатнім для доступу до запису, незалежно від того, якому бізнес-підрозділу належить цей запис. Якщо перевірка права пройшла задовільно, це означає, що користувач має відповідний доступ для виконання відповідної дії.
Нотатка
Якщо користувач належить до робочої групи, яка відповідає за запис, цей користувач також має доступ до запису.
Доступ ролі
Завдяки своїм ролям безпеки користувачі також можуть мати доступ до виконання дій із записами. У цьому випадку враховується рівень доступу права, яке має роль. Є чотири основні сценарії, що відповідають різним рівням доступу, що не є рівнем доступу «Користувач», які передбачені для відповідальних осіб.
| Запис належить користувачеві або команді, членом якої є користувач | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня користувача, або входити до складу робочої групи, яка має таку роль. *Дивіться примітку нижче. |
| Запис належить до тієї ж бізнес-одиниці, що й користувач | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня Підрозділ, або входити до складу робочої групи, яка має таку роль. |
| Запис належить тій самій бізнес-одиниці, що й команда, членом якої є користувач | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня Підрозділ, або входити до складу робочої групи, яка має таку роль. |
| Запис належить до бізнес-одиниці, яка є нащадком бізнес-одиниці користувача | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня Головна та підлеглі організаційні одиниці, або входити до складу робочої групи, яка має таку роль. |
| Запис належить до бізнес-одиниці, яка є нащадком бізнес-одиниці користувача або нащадком бізнес-одиниці команди, членом якої є користувач | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня Головний та підлеглі підрозділи, або входити до складу робочої групи, яка має таку роль. |
| Запис належить до бізнес-одиниці, яка не є нащадком бізнес-одиниці користувача | У цьому випадку користувач повинен мати призначену роль із правом на доступ щонайменше рівня організації, або входити до складу робочої групи, яка має таку роль. |
Нотатка
*Для ролей, призначених командам із привілеями користувача базового рівня, також діє конфігурація успадкування ролей. Якщо для робочої групи зазначено Успадковування права учасника як Лише права робочої групи, користувач зможе використовувати це право тільки відносно записів, за які відповідає його робоча група. Докладніші відомості можна дізнатися в розділі Успадкування права члена робочої групи.
Спільний доступ
Ще одним способом отримання доступу до запису без призначення користувачу конкретної ролі з відповідним правом є спільний доступ. Коли користувач із відповідними правами надає спільний доступ до запису користувачу, робочій групі або організації, виникає «спільний доступ». Є п’ять способів, якими користувач може отримати спільний доступ до запису.
| Запис був переданий безпосередньо користувачеві | Якщо запис надається користувачу в режимі спільного доступу для виконання певної дії, цей користувач має доступ до виконання цієї дії за умови, що він пройшов перевірку права. |
| Відповідний запис було надано безпосередньо користувачеві | Наведений далі сценарій відбувається, коли запис А пов’язаний із записом Б. Якщо користувач має спільний доступ для виконання певної дії із записом А, він також має успадкований доступ для виконання тієї самої дії із записом Б, якщо цей користувач пройшов перевірку права. |
| Записом поділилися з командою, до якої належить користувач | Якщо запис надається робочій групі в режимі спільного доступу для виконання низки дій, користувачі, що належать до цієї робочої групи, мають доступ до виконання цих дій за умови, що вони пройшли перевірку права. |
| Відповідним записом було надано доступ до команди, до якої належить користувач | Наведений далі сценарій відбувається, коли запис А пов’язаний із записом Б. Якщо до запису А робочій групі надається спільний доступ для виконання низки дій, а при цьому запис А пов’язаний із записом Б, користувачі, що є учасниками цієї робочої групи, матимуть доступ до виконання цих дій у обох записах – А і Б за умови, що вони пройшли перевірку права. |
| Запис був переданий всій організації | Якщо запис надається організації в режимі спільного доступу для виконання низки дій, всі користувачі, що належать до цієї організації, можуть виконувати ці дії за умови, що вони пройшли перевірку права. |
Ієрархічний доступ
Ієрархічний доступ відбувається лише в разі увімкнення в цій організації керування ієрархічним доступом саме для цієї таблиці, а також якщо цей користувач є керівником.
У цьому випадку користувач має доступ до запису, якщо задовольняються обидві з наведених далі умов.
- Керівнику безпосередньо або через робочу групу, яка має рівень доступу «Бізнес-підрозділ» або «Головна та підлеглі організаційні одиниці», призначено роль безпеки.
- Плюс будь-що із наведеного далі.
- За запис відповідає безпосередній підлеглий працівник.
- Безпосередній підлеглий працівник є учасником робочої групи відповідального.
- Спільний доступ до запису надано задля виконання необхідної дії з безпосереднім підлеглим працівником.
- Спільний доступ до запису надано задля виконання необхідної дії з робочою групою, до якої належить безпосередній підлеглий працівник.
Перевірка доступу до запису
Для кожного запису, який відображається у веб-клієнті, користувач має можливість побачити, як йому було надано доступ до запису за допомогою опції «Перевірити доступ » на панелі команд. Користувач також може бачити інших користувачів, які мають доступ до запису, і свій відповідний рівень доступу.
Існує два параметри бази даних середовища, які слід налаштувати для використання функції Хто має доступ . Інсталюйте інструмент OrganizationSettingsEditor і встановіть для наступного значення true:
- IsAccessCheckerAllUsersEnabled: Це дозволяє адміністратору бачити, хто має доступ до рядка.
- IsAccessCheckerNonAdminAllUsersEnabled: це дозволяє адміністратору, власнику запису та користувачам, які мають доступ до рядка, бачити, хто має доступ.
Див. також
Ролі та привілеї безпеки
Створюйте користувачів
Створення або редагування ролі безпеки для керування доступом
Відео: Перевірка функції доступу