Мова: Українська
Функція дозволів на рівні поля розширює модель безпеки ActivityInfo, дозволяючи адміністраторам контролювати доступ до певних полів у формі. Ця функція надає адміністраторам гнучкість у розробці форм, з якими зможуть працювати декілька користувачів з різними ролями без шкоди для безпеки.
У базі даних, що містить форму "Пацієнти", яка використовується для управління медичними записами, користувачі можуть збирати таку інформацію, як імена пацієнтів, стать, дата народження, національні ідентифікаційні номери, номери телефонів, фізичні адреси, діагнози та деталі лікування. Хоча ця інформація необхідна для надання допомоги, не кожен користувач у медичному закладі повинен мати доступ до повного запису пацієнта.
Така інформація, як імена пацієнтів, номери телефонів, адреси та ідентифікаційні номери, може безпосередньо ідентифікувати особу. Цей тип інформації вважається персональними даними (ПД) і повинен бути захищений для забезпечення приватності та конфіденційності пацієнтів.
Дозволи на рівні поля дозволяють адміністраторам обмежувати доступ до конфіденційних даних, щоб лише авторизовані користувачі, такі як клініцисти або медичні працівники, могли переглядати або редагувати ці поля. Інші користувачі можуть продовжувати працювати з тими ж записами, поки конфіденційна інформація залишається прихованою.
Якщо роль користувача не має дозволу на "перегляд" певного поля, значення поля залишаються прихованими. Це означає, що користувач може продовжувати отримувати доступ до запису та працювати з ним, але обмежена інформація для нього невидима. Якщо роль користувача не має дозволу на "редагування" певного поля, користувач не зможе вносити жодних змін у значення цього поля.
Налаштування дозволів на рівні поля для перегляду та редагування значень полів
Адміністратор може надавати дозволи на перегляд або редагування значень полів на рівні ролі користувача. У цьому прикладі ми маємо форму "Пацієнти" з наступними полями:
- Повне ім'я
- Стать
- Дата народження
- Номер телефону
- Емейл
- Відомі алергії
- Наявні захворювання
- Клінічні нотатки
Є дві різні ролі: Реєстратор та Клінічний спеціаліст.
- Реєстратор може переглядати та редагувати демографічну інформацію пацієнта.
- Клінічний спеціаліст може переглядати демографічну інформацію та редагувати клінічні нотатки, відомі алергії та наявні захворювання.
Роль користувача "Реєстратор"
Реєстратор — це перша людина, яка зустрічає пацієнта. Його робота полягає у зборі даних пацієнта, таких як повне ім'я, стать, дата народження, номер телефону та емейл.
Таким чином, їм не дозволено переглядати або редагувати інші поля в таблиці "Пацієнти".
Нижче наведено кроки для налаштування цієї ролі, щоб дозволити перегляд та редагування лише необхідних полів.
- Перейдіть до Налаштування бази даних і виберіть Ролі.
- Виберіть роль Реєстратор, для якої ви хочете задати умови на рівні поля.
- Натисніть Надати ресурси, виберіть форму та натисніть Виберіть ресурс.
- Надайте ролі базові дозволені операції.
- Прокрутіть вниз на панелі дозволів праворуч і виберіть опцію Керування умовами._
- Виберіть Додати умову на рівні поля, щоб створити умову, яка дозволяє користувачам з роллю Реєстратор переглядати та редагувати значення полів, коли виконуються задані умови. У розділі Дозволити виберіть Перегляд, а в розділі Коли виберіть всі.
Це буде виглядати так: Дозволити перегляд, коли застосовуються всі наступні умови…
- Додайте правила, які повинні застосовуватися до наведеного вище твердження.
Тепер умова буде виглядати так: … Дозволити перегляд, коли застосовуються всі наступні умови: не є Відомі алергії, не є Наявні захворювання, не є Клінічні нотатки.
Це означає, що будь-яке інше поле, не зазначене в цій умові, може бути переглянуте та відредаговане користувачами з цією роллю.
Натисніть Задати умови.
- Прокрутіть вниз і натисніть Зберегти на панелі управління ролями.
- Користувачі з цією роллю можуть редагувати та переглядати всі інші поля, крім Відомі алергії, Наявні захворювання та Клінічні нотатки, які залишаються прихованими.
Роль користувача "Клінічний спеціаліст"
Після реєстрації пацієнта наступним кроком є візит до клініциста, якому в системі призначено роль користувача Клінічний спеціаліст.
Клінічний спеціаліст повинен бачити деталі пацієнта, такі як повне ім'я, дата народження та стать, але не має права редагувати ці поля. Однак, йому потрібно редагувати такі деталі, як відомі алергії, наявні захворювання та клінічні нотатки.
Нижче наведено кроки для налаштування цієї ролі для доступу лише до необхідних полів.
- Перейдіть до Налаштування бази даних і виберіть Ролі.
- Виберіть роль Клінічний спеціаліст, для якої ви хочете задати умови на рівні поля.
- Натисніть Надати ресурси, виберіть форму та натисніть Виберіть ресурс.
- Надайте ролі базові дозволені операції.
- Прокрутіть вниз на панелі дозволів праворуч і виберіть опцію Керування умовами._
- Виберіть Додати умову на рівні поля, щоб створити умову, яка дозволяє користувачам з роллю Клінічний спеціаліст переглядати та редагувати значення полів, коли виконуються задані умови. У розділі Дозволити виберіть Редагувати, а в розділі Коли виберіть будь-який.
Це буде виглядати так: Дозволити редагування, коли застосовується будь-яка з наступних умов…
- Додайте правила, які повинні застосовуватися до поля вище.
Тепер умова буде виглядати так: … Дозволити редагування, коли застосовується будь-яка з наступних умов: є Відомі алергії, є Наявні захворювання, є Клінічні нотатки.
Це означає, що будь-яке інше поле, не зазначене в цій умові, не може бути відредаговане користувачами з цією роллю.
Натисніть Задати умови.
- Прокрутіть вниз і натисніть Зберегти на панелі управління ролями.
- Користувачі з цією роллю можуть редагувати поля Відомі алергії, Наявні захворювання та Клінічні нотатки і переглядатимуть решту полів.
Всі інші поля залишаються видимими для клінічного спеціаліста, але виділені сірим кольором.
Як дозволи на рівні поля взаємодіють з іншими налаштуваннями
Дозволи на рівні поля не працюють ізольовано. Їхня поведінка тісно пов'язана з іншими налаштуваннями форми, такими як:
Обов'язкові поля
Якщо користувач не має доступу до поля, позначеного як обов'язкове, він не зможе додати новий запис, оскільки система не може підтвердити, чи було заповнене обов'язкове поле.
Виняток становить випадок, коли для обов'язкового поля визначено значення за замовчуванням. У цьому випадку система може автоматично заповнити поле, дозволяючи користувачеві зберегти запис навіть без прямого доступу до нього.
Правила перевірки та обчислення
Правила перевірки та обчислювані поля залежать від доступу до значень базових полів.
Якщо користувач не має доступу на перегляд до поля, що використовується в правилі перевірки або обчисленні:
- Система не може оцінити правило перевірки.
- Обчислення, що залежать від цього поля, не можуть бути виконані.
Це тому, що поле приховане і, отже, недоступне для логіки, яка керує перевіркою або обчисленнями.
Приклад: Якщо правило перевірки перевіряє, чи повинен вік бути більшим за 18, але поле Дата народження приховане, правило не може бути оцінене.
Розробляйте правила перевірки та обчислення, використовуючи поля, доступні для відповідних ролей користувачів, або переконайтеся, що приховані поля не ставлять під загрозу критичний дизайн форми.
Звіти та збережені аналізи
Дозволи на рівні поля поводяться по-різному в контексті збережених звітів.
Якщо звіт збережено в базі даних і він включає в себе поля, які зазвичай приховані для певних користувачів, ці користувачі все одно зможуть переглядати ці поля у звіті.
Така поведінка передбачає, що творець звіту навмисно включив ці поля і хоче, щоб вони були видимі для користувачів, які мають доступ до звіту. Це узгоджується з тим, як функціонують параметри ролі.
Якщо творці звітів хочуть обмежити доступ до конфіденційних полів у звітах, вони повинні розглянути наступне:
- Збереження звітів у папках з обмеженим доступом.
- Обмеження доступу до самого звіту на основі ролей користувачів.