UA127351C2 - Спосіб надання прав стосовно прав на роботу для значень поля форми - Google Patents

Abstract

У даному винаході описано спосіб надання прав стосовно прав на роботу для значень поля форми, включаючи крок надання прав на роботу для значень поля форми та крок вибору отримувача, крок надання прав на роботу для значень поля форми включає: S1: вибір форми, яка має бути авторизована, та відображення полів у формі, для яких потрібен контроль права на роботу, S2: надання прав на роботу для кожного значення полів відповідно, де отримувачем є одна або кілька ролей, роллю є незалежна особа, а не група або клас, одна роль може бути пов'язана з унікальним користувачем у один й той самий період, та один користувач може бути пов'язаний з однією або кількома ролями. Даний винахід може досягати надання відповідних прав на роботу для значень поля форми та покращувати якості управління системою. У даному способі кілька авторизовуваних ролей можуть бути вибрані одночасно з авторизацією серії, тим самим покращуючи ефективність авторизації. Окрім цього, даний спосіб підтримує авторизацію шаблону. Поєднано два способи для того, щоб суттєво покращити ефективність надання прав на роботу для значень поля форми у системі. WO/2019/007260 2 PCT/CN2018/093432

Description

Даний винахід відноситься до способу надання прав стосовно форми в системах адміністративного програмного забезпечення, таких як ЕКР, і, зокрема, він відноситься до способу надання прав стосовно прав на роботу для значень поля форми.

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

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

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

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

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

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

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

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

Права, надані користувачу відповідно до цього механізму відношення, зазвичай діляться на наступні три форми: 1. Як показано на Фіг. 1, право безпосередньо надано користувачу, де недоліком є багата кількість роботи та частота та трудомісткість операції. При змінах співробітника (як наприклад, переведення або прийом на роботу) всі права стосовно форми на роботу, пов'язані зі співробітником, мають бути скоректовані відповідним чином. Особливо багато прав стосовно форми для адміністраторів в компанії. Через те, що коригування прав містить багато роботи та є трудомістким, існує висока вірогідність виникнення помилок та упущень, які впливають на нормальну роботу підприємства та навіть призводять до 60 непередбачуваних витрат.

2. Як показано на Фіг. 2, роль (має природу класу/групи/посади/гтипу роботи) авторизовувана (одна роль може відноситися до кількох користувачів), користувач отримує права через свою роль, а оператор, що надає затвердження, має роль, що має природу групи або класу. 3. Як показано на Фіг. 3, поєднано два вище вказаних способи.

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

Спосіб контролю авторизації та робочого навантаження через роль, що має природу класу/групи/посту/типу роботи, має наступні недоліки: 1. При зміні прав користувача операції є складними. Під час фактичного використання системи права користувача часто мають бути скориговані під час роботи. Наприклад, під час обробки змін у правах співробітника, коли права співробітника мають відношення до ролі, яка була змінена, невірним є змінювати права всієї ролі через зміни у правах окремого співробітника тому, що ця роль також відноситься до інших співробітників, права яких залишаються незмінними. Для вирішення цієї ситуації створюється нова роль, яка відповідає співробітнику, права якого були змінені, або права безпосередньо надаються для співробітника (від'єднання від ролі) на основі вимог до прав. Вказані два способи обробки не лише займають багато часу, але також легко призводять до помилок у авторизації ролі у випадку великої кількості прав ролі. Для користувача дуже складно працювати, та дуже легко виникають помилки, що призводять до втрат користувачів системи.

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

Недолік першого варіанту є таким самим, що й для вище вказаного способу "прямої авторизації користувача". У другому варіанті додавання нової ролі включає створення, відношення та авторизацію ролі. Якщо багато ролей та багато користувачів, які відносяться до ролей, досить складно запам'ятати які користувачі відносяться до яких ролей. 2. Складно довго пам'ятати конкретні права, що містяться у ролі. Якщо роль має багато функціональних точок прав, з часом складно пам'ятати конкретні права для ролі, та ще більш складно пам'ятати різниці у правах між ролями з аналогічними правами. Права аналогічних ролей також легко сплутати. Якщо необхідно вказати нового користувача, майже неможливо точно визначити, як обрати відношення. 3. Через зміну прав користувача буде створено більше ролей (якщо нові ролі не створені,

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

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

Задача даного винаходу вирішується наступними технічними рішеннями: Спосіб надання прав стосовно прав на роботу для значень поля форми включає крок надання прав на роботу для значень поля форми та крок вибору отримувача, де відсутнє послідовне відношення між кроком надання прав на роботу для значень поля форми та кроком вибору отримувача. Крок надання прав на роботу для значень поля форми містить наступні кроки: 51: вибір форми, яка має бути авторизовувана, та відображення полів у формі, які потребує контролю прав на роботу; 52: надання прав на роботу для кожного значення полів відповідно; вказаний отримувач є однією або кількома ролями, вказаною роллю є незалежна особа, а не група або клас, одна роль може відноситися до унікального користувача у один й той самий період, та один користувач співвідноситься з однією або кількома ролями.

Вказане право на роботу включає одне з або обидва право на перегляд та право на зміни.

Режими відображення значення поля без права на перегляд включає: (1) відображення поля відповідно до значення поля, але з прихованим значенням поля за допомогою символу приховування; та (2) не відображення значення поля або поля відповідно до значення поля.

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

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

Назва вказаної ролі є унікальною у відділі, а номер ролі є унікальним у системі.

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

Спосіб надання прав на роботу для значень поля форми включає крок авторизації шаблону, який містить: (1) вибір отримувача та авторизовуваної форми, де у якості отримувача обирається одна або кілька ролей; (2) авторизацію отримувача: вибір існуючої ролі або створеного шаблону у якості шаблону авторизації, та надання прав на роботу значень поля форми у шаблоні авторизації для отримувача; та (3) отримання значення поля форми прав на роботу після збереження прав на роботу з або без змін.

Спосіб надання прав на роботу для значень поля форми включає крок авторизації прав на роботу для значень поля форми та крок вибору отримувача, де відсутнє послідовне відношення між кроком авторизації прав на роботу для значень поля форми та кроком вибору отримувача; крок надання прав на роботу для значень поля форми містить наступні кроки: 51: вибір форми, яка має бути авторизовувана; 52: вибір права на роботу, який має бути авторизовуваний; та 53: встановлення поля у формі, яка має обране право на роботу, щоб встановлене поле мало обране право на роботу (тобто, наявність відповідного права на роботу значення поля); вказаний отримувач є однією або кількома ролями, вказаною роллю є незалежна особа, а не група або клас, одна роль може відноситися до унікального користувача у один й той самий період, та один користувач співвідноситься з однією або кількома ролями.

Позитивні ефекти

Даний винахід має наступні переваги: 1) Даний винахід може гарантувати відповідне надання прав стосовно прав на роботу для значень поля форми, тим самим покращуючи якості управління системою. Право на роботу включає право переглядати та право вносити зміни, що є особливо корисним у випадках, коли потрібно авторизувати значення поля полів форми відповідно. Наприклад, у формі замовлення певний символ дозволяє переглядати "номер замовлення", "ім'я замовника", "адресу замовника", "сферу діяльності замовника", "модель продукції", "кількість продукції" та "ціну продукції за одиницю", але не дозволяє переглядати

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

Наприклад, Лі Сі провів останню операцію з надання прав на роботу значень поля контрактної форми для отримувача Чжана Саня о 11:00 21 травня 2015 р. Коли Чжана Саня обрано отримувачем та контракт обрано у якості форми, яка має бути авторизовувана, поточному оператору авторизації відображається, що остання авторизація форми контракту була проведена Лі Сі о 11:00 21 травня 2015 р. для Чжана Саня.

Якщо Чжан Сань не повинен мати права на перегляд змісту конфіденційного поля, але отримав право переглядати змісти конфіденційного поля у минулій авторизації для Чжана Саня, відповідальних за це можна знайти за допомогою пошуку останнього оператора авторизації у процесі відстеження послідовної звітності.

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

З) У цьому способі кілька авторизованих ролей можуть бути обрані одночасно з бо авторизацією серії, тим самим покращуючи ефективність авторизації. Окрім цього, цей спосіб підтримує авторизацію шаблону, якою є вибір існуючої ролі або створеного шаблону у якості шаблону авторизації, та безпосереднє надання (оновлення) прав на роботу для значень поля форми у шаблоні авторизації для отримувача (збережено після простої зміни). Операція з авторизації є простою та ефективною. Поєднано два способи для того, що суттєво покращити ефективність надання прав на роботу для значень поля форми у системі. 4) У такому застосуванні роллю є відношення до користувача один-на-один. Одна роль може відноситися до унікального користувача у один й той самий період, та один користувач відноситься до однієї або кількох ролей. Перевагою є те, що права можуть бути отримані доки користувач відноситься до ролі (користувач отримує права відповідної ролі), а змін у правах ролі набагато менше, ніж змін у правах користувача у традиційному механізмі. Через незначні зміни у кількості ролей, що мають природу незалежної особи (природа номеру посади або номер робочої станції), незважаючи на велику плинність кадрів, виникають кілька змін у номері посади/номері робочої станції (навіть якщо немає змін у певний період, роль не змінюється). Це сильно спрощує управління правами користувача та зменшує перевантаження системи. 5) Такі операції, як динамічне управління, прийом на роботу та переведення є простими, зручними, ефективними та високонадійними. Застосування прийому на роботу або зміна призначення або переведення в управлінні правами є простими. При зміні співробітника або користувача не потрібно скидати права. Для користувача лише має бути скасоване відношення або встановлене відношення до ролі. Для користувача, який більше не має ролі, відношення до ролі скасовується; та користувач, який приймає роль, відноситься до ролі колишнього номеру.

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

Наприклад, через те, що Чжана Саня було переведено або знято з посади, Чжан Сань більше не працює у ролі "покупця 3", та потім Чжан Сань скасовує відношення до "покупця 3".

Тим часом Лі Сі приймають на роботу у ролі "покупця 3", та лише потрібно віднести Лі Сі до ролі, тому Лі Сі автоматично отримує права на роботу для значень поля форми ролі "покупець

З". б) Традиційний механізм управління правами визначає роль як природу групи, типу роботи, класу, тощо. Роль має відношення до користувача "один для багатьох". Під час фактичного використання системи права користувача часто мають бути скориговані під час роботи.

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

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

Спосіб, вказаний у даному винаході, суттєво зменшує вірогідність виникнення помилок авторизації тому, що спосіб, вказаний у даному винаході, розглядає роль лише як незалежну особу, без врахування спільних властивостей кількох користувачів, віднесених до ролі, яка має природу групи у традиційному способі. Навіть якщо виникають помилки авторизації, вони виникають лише для користувача, пов'язаного з роллю. Однак у випадку традиційної ролі з природою групи, страждають усі користувачі, які пов'язані з роллю. Навіть якщо виникають 60 помилки авторизації, метод їх виправлення у даному винаході є простим та займає мало часу, а у випадку традиційної ролі, яка має природу групи, під час виправлення помилки необхідно розглядати спільні властивості прав всіх користувачів, які віднесені до ролі. Зміни є трудомісткими, складними та схильними до виникнення помилок, коли роль має багато функцій, та у багатьох випадках проблема не може бути вирішена іншим способом, окрім створення нової ролі. 8) В традиційному способі групової авторизації ролі, якщо роль має багато функціональних точок прав, з часом складно пам'ятати конкретні права для ролі, та ще більш складно пам'ятати різниці у правах між ролями з аналогічними правами. Якщо необхідно вказати нового користувача, неможливо точно визначити, як обрати відношення. У способі даного винаходу сама роль має природу номеру посади або номеру робочої станції, тому вибір буде більш простим. 9) Коли користувача переводять з посади, якщо багато прав переведеного користувача мають бути призначені іншому користувачу, під час оброблення необхідно розрізняти права переведеного користувача та створювати ролі, які будуть відноситися до інших користувачів відповідно. Операції є складними, довготривалими та схильними до виникнення помилок.

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

На фіг. 1 представлена схема послідовності дій безпосереднього надання прав системою користувачу на відомому рівні техніки;

На фіг. 2 представлена схема послідовності дій надання прав системою ролі, що має природу групи або класу, на відомому рівні техніки;

На фіг. 3 представлена схема послідовності дій безпосереднього надання прав системою користувача та ролі, що має природу групи або класу, на відомому рівні техніки;

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

На фіг. 5 представлене схематичне зображення вибору одного отримувача, форму обрано

Зо згідно з даним винаходом;

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

На фіг. 7 представлене схематичне зображення надання прав отримувача за допомогою шаблону авторизації згідно з даним винаходом; та

На фіг. 8 представлене схематичне зображення форми замовлення згідно з варіантом здійснення даного винаходу.

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

Варіант здійснення 1. У даному варіанті здійснення спочатку встановлюються поля, для яких контроль прав на роботу є необхідним, а потім встановлюються відповідні права на роботу.

Спосіб надання прав на роботу для значень поля форми включає крок надання прав на роботу для значень поля форми та крок вибору отримувача, де відсутнє послідовне відношення між кроком надання прав на роботу для значень поля форми та кроком вибору отримувача; крок надання прав на роботу для значень поля форми містить наступні кроки: 51: вибір форми, яка має бути авторизовувана, та відображення полів у формі, які потребує контролю права на роботу; 52: надання прав на роботу для кожного значення полів відповідно (поля, що потребують контролю права на роботу, вказані у 51, авторизуються, та зазвичай вважається, що значення поля, яке не вказане у 51 та не потребує контролю права на роботу, має право на перегляд та/або внесення змін), де право на роботу включає один або обидва право на перегляд та право на внесення змін.

Після завершення налаштування може бути визначено право отримувача переглядати або змінювати зміст (значення поля) кожного поля у формі.

Даний винахід може гарантувати відповідне надання прав стосовно прав на роботу для значень поля форми, тим самим покращуючи якості управління системою. Права на роботу включають право переглядати та право вносити зміни, що є особливо корисним у випадках, коли потрібно авторизовувати значення полів форми відповідно. Наприклад, у формі замовлення символ ролі клерка 1 (Чжан Сань) дає право переглядати "номер замовлення", "ім'я замовника", "адресу замовника", "сферу діяльності замовника", "модель продукції", "кількість бо продукції" та "ціну продукції за одиницю", але не дає право переглядати зміст (значення поля)

таких конфіденційних полів, як "номер телефону" та "контактна інформація". Завдяки даному способу відповідна авторизація може швидко відбуватися. У іншому прикладі клерк 1 (Чжан

Сань) має право переглядати зміст поля "ціна продукції за одиницю", але не має права змінювати зміст поля "ціна продукції за одиницю", та даний спосіб також може швидко встановлювати право. Налаштування показані на фіг. 5.

У цьому варіанті здійснення, як показано на фіг. 4, отримувач є однією або кількома ролями, роллю є незалежна особа, а не група або клас, одна роль може відноситися до унікального користувача у один й той самий період, та один користувач співвідноситься з однією або кількома ролями. Роль належить відділу, роль є унікальною у відділі, роль авторизується відповідно до змісту роботи ролі, та користувач отримує права через відповідну роль. Назва ролі є унікальною у відділі, а номер ролі є унікальним у системі. Під час переведення користувача з одного відділу у інший спочатку відношення користувача до ролі у оригінальному відділі скасовується, та потім користувач відноситься до ролі у новому відділі.

Далі були проаналізовані переваги способу надання прав стосовно прав на роботу для значень поля для користувача через роль, яка має природу незалежної особи: Користувач визначає (отримує) права через своє відношення до ролі. Якщо права користувача мають бути змінені, права, що належать ролі, коригуються для досягнення мети зміни прав користувача, якого віднесено до ролі. Після того, як користувача віднесено до ролі, користувач має всі права ролі на роботу.

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

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

Застосована у підприємстві або інституті, роль є еквівалентною номеру посади (тут номер посади не є посадою, а одна посада може мати кількох співробітників одночасно, а один номер посади може відповідати тільки одному співробітнику у один й той самий період часу).

Зо Наприклад, у системі компанії можуть бути створені наступні ролі: генеральний директор, заступник генерального директору 1, заступник генерального директору 2, керівник відділу продажів у Пекіні І, керівник відділу продажів у Пекіні Ії, керівник відділу продажів у Пекіні ПІ, інженер відділу продажів у Шанхаї 1, інженер відділу продажів у Шанхаї 2, інженер відділу продажів у Шанхаї 3, інженер відділу продажів у Шанхаї 4, інженер відділу продажів у Шанхаї 5, тощо. Відношення між користувачами та ролями є наступним: якщо Чжан Сань, співробітник компанії, обіймає посаду заступника генерального директора 2 компанії, а також є керівником відділу продажів у Пекіні ШІ ролями до яких має бути віднесено Чжана Саня є заступник генерального директора 2 та керівник відділу продажів у Пекіні І. та Жан Сан має права обох ролей.

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

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

Після того, як користувача було віднесено до ролі, користувача можна звільнити від відношення до ролі у будь-який час, та відношення між користувачем та іншою роллю може бути створено у

БО будь-який час.

Роль складається з: назва посади ж- номер посади, наприклад, співробітник цеху 1, співробітник цеху 2, співробітник цеху 3, тощо. Роль є незалежною особою та еквівалентна концепції номеру посади або номеру робочої станції, але відрізняється від ролі у традиційній системі управління правами. Концепція ролі у традиційній системі управління правами має природу групи або класу, як наприклад, пост, посада, тип роботи, тощо.

У наступному прикладі показано відношення серед співробітником, користувачем та роллю після того, як Чжан Сань, співробітник, почав працювати у компанії: 1. Прийом на роботу: після прийому співробітника на роботу роль відповідного номеру посту або номеру робочої станції безпосередньо обирається для користувача (співробітника), якого має бути віднесено. 60 Наприклад, коли Чжан Сань прийшов до компанії (компанія задала користувача для Чжана

Саня) та працює у відділі продажів І та відповідає за продажі холодильників у Пекіні (відповідна роль "інженер з продажів 5" у відділі продажів І), користувач Чжан Сань безпосередньо обирається та відноситься до ролі "інженер з продажів 5". 2. Додавання посади: Після того, як Чжан Сань відпрацював певний час, компанія призначає

Чжана Саня відповідальним за продажі телевізорів у Пекіні (відповідна роль "інженер з продажів 8" у відділі продажів І) та у якості контролера відділу після продажного обслуговування (відповідна роль "контролер відділу після продажного обслуговування 1"). Тому дві ролі "інженер з продажів 8" у відділі продажів І та "контролер відділу після продажного обслуговування І" у відділі після продажного обслуговування додатково відносяться до користувача Чжана Саня. У цьому випадку співробітника Чжана Саня віднесено до трьох ролей: "інженер з продажів 5" та "інженер з продажів 8" у відділі продажів І та "контролер відділу після продажного обслуговування !" у відділі після продажного обслуговування. Тому користувач Чжан Сань має права трьох ролей.

З. Пониження посади: Через деякий час компанія вирішила назначити Чжана Саня керівником відділу після продажного обслуговування (відповідно до ролі "керівник відділу після продажного обслуговування" у відділі після продажного обслуговування) та звільнити з інших посад. Тому користувача Чжана Саня віднесено до ролі "керівник відділу після продажного обслуговування" у відділі після продажного обслуговування та звільнено від відношення до попередніх трьох ролей ("інженер з продажів 5" та "Інженер з продажів 8" у відділі продаж І та "контролер відділу після продажного обслуговування !" у відділі після продажного обслуговування). У цьому випадку користувач Чжан Сань має тільки права ролі "керівник відділу після продажного обслуговування" у відділі після продажного обслуговування. 4. Коригування прав ролі (коригування прав самої ролі): якщо компанія вирішила додати права керівнику відділу після продажного обслуговування, необхідно тільки додати права до ролі керівника відділу після продажного обслуговування. Зі збільшенням прав ролі керівника відділу після продажного обслуговування права користувача Чжана Саня також збільшуються. 5. Звільнення: Через рік Чжан Сань звільнюється. Необхідно тільки скасувати відношення між користувачем Чжаном Санем та роллю "керівник відділу після продажного обслуговування" у відділі після продажного обслуговування.

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

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

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

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

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

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

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

Наприклад, Лі Сі провів останню операцію з надання прав на роботу значень поля контрактної форми для отримувача Чжана Саня о 11:00 21 травня 2015 р. Коли Чжана Саня 60 обрано отримувачем та контракт обрано у якості форми, яка має бути авторизована, поточному оператору авторизації відображається, що остання авторизація форми контракту була проведена Лі Сі о 11:00 21 травня 2015 р. для ЧУжана Саня.

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

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

Варіант здійснення 3. У цьому варіанті здійснення режими відображення значення поля без права на перегляд включають: (1) відображення поля відповідно до значення поля, але з прихованим значенням поля за допомогою символу приховування, як показано на фіг. 8, поля "номер телефону" та "контактна інформація" відображаються, але зміст полів приховано символом "7; (2) не відображення значення поля або поля відповідно до значення поля.

Значення поля з або без права вносити зміни також мають відрізнятися під час відображення. Наприклад, значення поля без права вносити зміни відображається сірим кольором, як показано на фіг. 8.

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

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

Варіант здійснення 4. У цьому варіанті здійснення спосіб надання прав стосовно прав на роботу для значень поля форми включає крок авторизації шаблону, який містить: (1) вибір отримувача та форми, яка має бути авторизована, де у якості отримувача обирається одна або кілька ролей; (2) авторизацію отримувача: вибір існуючої ролі або створеного шаблону у якості шаблону авторизації, та надання прав на роботу значень поля форми у шаблоні авторизації для отримувача; та (3) отримання значення поля форми прав на роботу після збереження прав на роботу з або без змін.

Як показано на фіг. 7, у способі надання прав стосовно шаблону спочатку обирається отримувач, клерк 1 (Чжан Сань), обирається форма "форма замовлення", яка має бути авторизована, обирається створений шаблон 1 як шаблон авторизації, права на роботу для значень поля форми у створеному шаблоні 1 використовуються як права на роботу для значення поля для клерка 1 (Чжан Сань), а права на роботу для значень поля форми для клерка 1 (Чжан Сань) отримуються після збереження прав на роботу для значень поля форми у створеному шаблоні 1 з або без змін.

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

Варіант здійснення 5. У цьому варіанті здійснення спочатку обирається право на роботу, а потім встановлюються поля, що мають право на роботу.

Спосіб надання прав стосовно прав на роботу для значень поля форми включає крок 60 надання прав на роботу для значень поля форми та крок вибору отримувача, де відсутнє послідовне відношення між кроком надання прав на роботу для значень поля форми та кроком вибору отримувача. Крок надання прав на роботу для значень поля форми містить наступні кроки: 51: вибір форми, яка має бути авторизована; 52: вибір права на роботу, яке має бути авторизоване; та 53: встановлення поля у формі, яка має обране право на роботу, щоб встановлене поле мало обране право на роботу (тобто, наявність відповідного права на роботу значення поля); отримувач є однією або кількома ролями, роллю є незалежна особа, а не група або клас, одна роль може відноситися до унікального користувача у один й той самий період, та один користувач співвідноситься з однією або кількома ролями.

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

Claims (7)

ФОРМУЛА ВИНАХОДУ

1. Спосіб надання прав стосовно прав на роботу для значень поля форми, що включає крок надання прав на роботу для значень поля форми та крок вибору отримувача, де відсутнє послідовне відношення між кроком надання прав на роботу для значень поля форми та кроком вибору отримувача; крок надання прав на роботу для значень поля форми містить наступні кроки: 51: вибір форми, яка має бути авторизована, та відображення полів у формі, які потребують контролю права на роботу; та 52: надання прав на роботу для кожного значення полів відповідно; вказаний отримувач є однією або кількома ролями, роллю є незалежна особа, а не група або Зо клас, одна роль може бути пов'язана з унікальним користувачем у один й той самий період, та один користувач пов'язаний з однією або кількома ролями; при цьому вказане право на роботу містить одне з або обидва: право на перегляд та право на внесення змін.

2. Спосіб надання прав стосовно прав на роботу для значень поля форми за п. 1, який відрізняється тим, що режими відображення значення поля, що не має права на перегляд, складаються з: (1) відображення поля відповідно до значення поля, але з прихованим значенням поля за допомогою символу приховування; та (2) невідображення значення поля або поля відповідно до значення поля.

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

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

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

6. Спосіб надання прав стосовно прав на роботу для значень поля форми за п. 4 або 5, який відрізняється тим, що, коли користувач переводиться у інший відділ, зв'язок користувача з роллю у початковому відділі скасовується, а потім користувач пов'язується з роллю у новому відділі.

7. Спосіб надання прав стосовно прав на роботу для значень поля форми за п. 1, який відрізняється тим, що також включає крок авторизації шаблону, який містить: (1) вибір отримувача та авторизованої форми, вибір однієї або більше ролей як отримувача; (2) авторизацію отримувача: вибір існуючої ролі або створеного шаблону як шаблону авторизації, та надання прав на роботу для значень поля форми у шаблоні авторизації для бо отримувача; та