Дозволи та організації

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

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

Структурований словник дозволів, який використовується в редакторах ролей, наведено в розділі /reference/permissions.

Модель організації

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

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

Структура дозволу

Більшість дозволів мають таку структуру:

entity:action:scope

Наприклад, customer:read:assigned означає, що роль може читати призначені записи клієнтів, але не обов’язково всі записи клієнтів в організації.

Адміністрування організації використовує admin сутність із такою самою структурою дії та області дії (наприклад, admin:list:all). Ролі, які керують дочірніми організаціями та ролями користувачів, зазвичай містять разом кілька дозволів admin:*. Не плутайте їх з окремим типом облікового запису глобального адміністратора платформи Scoutello. Його використовують лише працівники Scoutello, і він надає доступ до інструментів для роботи між клієнтами.

Як бічна панель використовує дозволи

Панель керування приховує посилання, якими поточний сеанс не має користуватися. Приклади:

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

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

Порядок дій для служби підтримки

Якщо доступ виглядає неправильним:

1. Перевірте активну організацію.
2. Перевірте роль користувача в цій організації.
3. Перевірте відповідну сутність, дію та область дії.
4. Перевірте потрібний модуль, його поточний ліміт і всі заплановані зміни оплати.
5. Перевірте зв’язки з обмеженням за призначенням для записів, які мають бути видимими.
6. Визначте, чи є користувач оператором платформи, чи учасником організації.
7. Не надавайте широкі можливості адміністрування організації (сутність admin), якщо користувачеві не потрібно керувати структурою організації та ролями.

Пов’язані поняття: Довідник: дозволи, Огляд панелі керування.