Ролі в робочому просторі та кастомні RBAC

Elido має чотири вбудовані ролі в робочому просторі. Вони підходять для більшості команд; кастомні ролі на плані Business дозволяють точно налаштувати доступ, коли "Admin" — це забагато, а "Editor" — замало.

Вбудовані ролі#

Роль	Посилання	Учасники	Домени	Білінг	Журнал аудиту
Owner	RW	RW	RW	RW	R
Admin	RW	RW	RW	R (лише перегляд)	R
Editor	RW	R	R	—	R (тільки власні дії)
Viewer	R	R	R	—	—

R = читання (read), RW = читання/запис (read/write), — = немає доступу. Ця таблиця є спрощенням — деталі дивіться в примітках до кожного розділу нижче.

Що насправді може робити кожна роль#

Owner. Роль, яку отримує той, хто створив робочий простір, а також усі, кого підвищили до цієї ролі. Тільки Owner може:

Змінювати тарифний план або спосіб оплати.
Видалити робочий простір.
Підвищувати / понижувати інших Owner.

У робочому просторі завжди повинен бути принаймні один Owner. Якщо останній Owner виходить, система автоматично підвищує Admin з найдовшим стажем.

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

Editor. Роль за замовчуванням для окремих учасників. Може створювати / редагувати / видаляти посилання, виконувати масовий імпорт, генерувати QR-коди та керувати вебхуками. Не може запрошувати людей, змінювати налаштування робочого простору або додавати власні домени.

Viewer. Доступ лише для читання у всьому дашборді. Бачить посилання та аналітику; не може натискати жодні кнопки дій. Корисно для стейкголдерів, аудиторів та користувачів BI / Looker з доступом лише для читання.

Кастомні ролі (план Business)#

Робочі простори на плані Business можуть визначати кастомні ролі за допомогою чекліста дозволів. Набір дозволів:

links.read / links.write
analytics.read
domains.read / domains.write
members.read / members.write
billing.read / billing.write
audit_log.read
webhooks.write
api_keys.create (видача ключів з роллю ≤ вашої власної)
qr.read / qr.write
bio.write
branding.write (white-label налаштування)

Створіть таку роль у Settings → Roles → New role. Виберіть назву, відмітьте дозволи, збережіть. Призначте її учаснику у списку учасників. Ролі можна редагувати пізніше; зміни застосовуються протягом 60 секунд.

Ролі та ключі API#

Ключі API прив'язані до ролей. Ключ API з роллю editor може створювати посилання; ключ API з роллю admin може робити все те саме, що й користувач з роллю admin. Видача ключа з роллю вищою за вашу власну роль у робочому просторі заборонена — API поверне помилку 403.

Пониження ролі користувача не анулює його ключі API автоматично. Вони зберігають ту роль, яка була у них на момент видачі. Щоб застосувати пониження, анулюйте ключі користувача вручну у Settings → API keys → Manage user keys.

Передача права власності#

Щоб передати право власності комусь іншому:

Відкрийте рядок учасника → Set role: Owner.
За бажанням змініть власну роль на Admin або нижчу.

Спеціального майстра «передачі робочого простору» немає — кожен Owner має рівні права, і ви можете мати скільки завгодно Owner. Для чистої передачі спочатку підвищіть нового Owner, переконайтеся, що він має доступ, а потім понизьте себе.

Видалення учасника#

Видалені учасники негайно втрачають доступ до дашборду. Їхні персональні ключі API анулюються протягом 60 секунд. Посилання, створені ними, залишаються у власності робочого простору (а не користувача), тому робота посилань не переривається.

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

Усунення несправностей#

Користувач каже, що не бачить створене ним посилання. Перевірте його роль — якщо ви понизили його до Viewer, він все ще бачить посилання, якщо він у робочому просторі, але не може його редагувати. Якщо ви також видалили його з папки, відновіть доступ до папки.

Ключ API працює навіть після того, як я понизив роль користувача. Ключі API зберігають свою початкову роль. Анулюйте ключ у Settings → API keys, щоб змусити користувача випустити новий.

У кастомній ролі не вистачає потрібного мені дозволу. Набір дозволів фіксований (див. список вище). Якщо не вистачає чогось дійсно критичного, напишіть на support@elido.app з описом вашого випадку — ми додаємо нові можливості до набору дозволів за наявності попиту.

Масова зміна ролей. Використовуйте API SCIM: членство в групах у вашому IdP відповідає ролям у Elido. Див. SSO + SCIM для налаштування. Ролі, керовані SCIM, не можна редагувати в дашборді — вони відповідають даним з IdP.