Модулі користувача

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

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

Статуси користувачів

Обліковий запис користувача може бути декількох станів:

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

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

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

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

Видалений обліковий запис можна відновити, але відновити видалену особисту інформацію неможливо.

Забутий Обліковий запис було знеособлено та видалено персональні дані відповідно до GDPR

GDPR та видалення облікових записів користувачів

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

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

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

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

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

Нетипові примітки до об'єктів
Персональні знаки на об'єктах
Особисті кишені з предметами

Але скасування облікового запису не видаляє особисті дані – ім'я та електронну пошту.

Анонімізація – забуття

Виконати вимоги GDPR можна і за допомогою анонімізації. Анонімізувати можна тільки скасовані рахунки.

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

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

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

Анонімізація повністю відповідає вимогам GDPR. Він не повинен відповідати внутрішнім правилам організації, і перед його виконанням адміністратор повинен переконатися, що він виконаний відповідно до внутрішніх методик і правил.

Особисті рахунки та їх підрахунок

Для обчислення активних користувачів підраховуються рахунки в стані активного, запрошеного і заблокованого (так звані активні статуси). Рахунки в інших статусах не рахуються.

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

Налаштування прав користувача

Права системи

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

Права, що виникають у зв'язку з об'єктом

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