Права доступа и организации

Доступ внутри организации определяется ролями, связанными с детализированными разрешениями. Видимость разделов панели управления зависит от активной организации, назначенных ролей, области действия разрешений и подключённых модулей подписки.

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

Описание структурированного набора разрешений, используемого в редакторах ролей, см. в разделе /reference/permissions.

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

Данные Scoutello относятся к определённой организации. Один пользователь может состоять более чем в одной организации и иметь разные роли в каждой из них. Перед диагностикой проблем с доступом, отсутствующими записями или пунктами боковой панели всегда проверяйте активную организацию.

Организации также могут иметь иерархию. Крупные клиенты могут использовать дочерние организации для объектов, команд, местоположений или брендов, а родительская организация помогает управлять общими отношениями с клиентом.

Структура разрешений

Большинство разрешений имеют следующую структуру:

entity:action:scope

Например, customer:read:assigned означает, что роль может просматривать назначенные записи клиентов, но не обязательно всех клиентов в организации.

Для администрирования организации используется сущность admin с той же структурой действий и областей действия (например, admin:list:all). Роли, управляющие дочерними организациями и ролями пользователей, обычно включают несколько разрешений admin:* одновременно. Не путайте это с отдельным типом учётной записи глобального администратора платформы Scoutello: он используется только сотрудниками Scoutello и открывает инструменты для работы между клиентами.

Как боковая панель использует разрешения

Панель управления скрывает ссылки, которыми текущая сессия не должна пользоваться. Примеры:

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

Отсутствующий пункт меню часто связан с правилами разрешений, а не со сбоем развёртывания.

Порядок действий при обращении в поддержку

Если доступ работает неправильно:

1. Проверьте активную организацию.
2. Проверьте роль пользователя в этой организации.
3. Проверьте соответствующие сущность, действие и область действия.
4. Проверьте необходимый модуль, его текущее доступное количество и ожидающие изменения тарификации.
5. Проверьте связи «только назначенные» для записей, которые должны быть видны.
6. Уточните, является ли пользователь оператором платформы или участником организации.
7. Не предоставляйте широкие возможности администрирования организации (сущность admin), если пользователю не требуется управлять структурой организации и ролями.

Связанные понятия: Справочник: разрешения, Обзор панели управления.