Які ролі користувачів існують і чим вони відрізняються?


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

Швидкий вибір ролі

Якщо вам потрібно:

  • повний контроль над акаунтом — Власник;
  • керувати системою на рівні всієї компанії — Адміністратор акаунту;
  • керувати людьми в межах команди — Адміністратор команди;
  • керувати людьми в межах відділу — Адміністратор відділу;
  • щоденна робота в задачах і проєктах — Користувач;
  • обмежений доступ для зовнішнього виконавця — Гість;
  • лише перегляд без змін — Читач;
  • зберегти контакт людини без доступу в систему — Контакт.

Коротке порівняння ролей

РольРівень доступуВхід у системуТипове застосування
ВласникВесь акаунтТакГоловний адміністратор акаунту
Адміністратор акаунтуВесь акаунтТакОпераційне адміністрування
Адміністратор командиСвоя командаТакКерівник команди
Адміністратор відділуСвій відділТакКерівник відділу
КористувачДоступні йому проєктиТакСпівробітник / клієнт
ГістьЛише дозволені задачіТакФрілансер / підрядник
ЧитачЛише переглядТакСпостерігач / аудитор
КонтактДоступу немаєНіКонтактна картка

Що важливо знати про кожну роль

  • Власник акаунту — має максимальні права, доступ до адміністративного API-токена, може видалити акаунт.
  • Адміністратор акаунту — керує налаштуваннями, учасниками, проєктами, даними, оплатою, може бачити приховані елементи за наявності права «Перегляд прихованої інформації». На відміну від власника, не має доступу до видалення акаунту та адміністративного API-токена.
  • Адміністратор команди — керує учасниками своєї команди та їх доступами, може мати права на створення проєктів, редагування даних, керування витратами/таймерами у межах команди.
  • Адміністратор відділу — аналогічний до адміністратора команди, але область дії прав обмежена відділом.
  • Користувач  — базова робоча роль: працює в проєктах, куди його додано. Зазвичай може створювати задачі, коментувати, додавати файли. Право коментувати чужі задачі є окремим перемикачем: якщо його вимкнути — учасник зможе коментувати лише ті задачі, де він є автором або відповідальним.
  • Гість — працює тільки в дозволеному контексті (свої або явно відкриті задачі), не бачить контакти інших користувачів і фінансові дані. За потреби гостю можна дозволити створення задач. Важливий нюанс: якщо гостя запросити у вкладену підзадачу, йому автоматично відкривається видимість усієї ієрархії задач угору (батьківська задача та підзадачі вищих рівнів).
  • Читач — лише перегляд, без створення, редагування і коментування. Роль не тарифікується; кількість читачів в акаунті може бути до x2 від кількості оплачених основних учасників.
  • Контакт — не має входу в систему, зберігається як картка людини для довідкових цілей. Контакт можна створити вручну або конвертувати з акаунту видаленого співробітника — щоб зберегти його дані.

Адміністративні права: як працює гнучкість

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

Права адміністратора акаунту:

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

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

Функціональні ролі в проєкті та задачах

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

  • Керівник проєкту — може редагувати проєкт, задачі, підзадачі і коментарі цього проєкту, додавати співробітників і керувати складом учасників (опція включається в налаштуваннях акаунту). Технічно керівником може бути будь-який учасник, але призначати “гостя” керівником не рекомендовано.
  • Відповідальний проєкту — автоматично підставляється у поле «Відповідальний» при створенні нових задач у цьому проєкті.
  • Учасник проєкту — бачить проєкт і усі задачі, файли та коментарі цього проєкту.
  • Автор задачі — той, хто створив задачу.
  • Відповідальний за задачу — виконавець задачі.
  • Підписник задачі — отримує сповіщення про дії в задачі.

Ключова різниця:

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

Поширені помилки при налаштуванні ролей

  • Давати роль «Адміністратор акаунту» там, де достатньо «Адміністратор команди».
  • Змішувати «Гість» і «Читач» (гість може брати участь у задачах, читач — ні).
  • Забувати перевіряти окремі перемикачі прав після призначення ролі.
  • Призначати надмірні права «про всяк випадок» замість принципу мінімально необхідного доступу.

Рекомендований підхід

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