Содержание
Участники, роли и видимость
Раздел: Доменная модель заказов и исполнения.
Назначение: Контракт. Продукт: ShariX Open.
Для кого: Администратор · Разработчик · Поддержка · Рецензент и приёмщик · Нейросеть.
Темы: Заказы → Модель · Доступ → Полномочия · Доступ → Объектные права.
Эта страница различает участника заказа, пользователя приложения и сторону обязательства. Названия групп и ограничения ниже сверены с опубликованными исходниками; выдача прав и поведение конкретной установки здесь не проверялись.
Конкретные роли сотрудников сервиса
| Название в приложении | Код | Что обозначать этим названием в сценарии |
|---|---|---|
| Администратор сервиса | METASERVICE-ADMIN | Предусмотренные настройки сервиса, категорий, ключей и финансовые операции; их доступ проверяется отдельно. |
| Модератор сервиса | METASERVICE-SUPERVISOR | Оперативное сопровождение исполнения и предусмотренные действия модерации. |
| Поддержка сервиса | METASERVICE-SUPPORT | Сопровождение обращений и доступного контекста заказа. |
| Техподдержка сервиса | METASERVICE-TECHSUPPORT | Техническое сопровождение в предусмотренном объёме. |
Это имена реальных ролей, а не четыре взаимозаменяемых обозначения любого сотрудника. При описании действия указывать нужную роль и контекст: например, Администратор сервиса меняет разрешённые настройки, а вопрос клиента о ходе заказа сопровождает Поддержка сервиса. Назначение сотруднику обязанности не создаёт недостающую операцию или право доступа.
В проверках заказов все четыре кода входят в METASERVICE_ORDER_STAFF_ROLES. Из этого не следует, что у них одинаковые административные формы или разрешены все переходы: матрица интерфейса и бизнес-операция применяют собственные ограничения. Например, metaservice_edit, metaservice_generate_key, metaservice_payments и изменение service_category ограничены METASERVICE-ADMIN; работа с тарифом предусматривает также отдельные роли модерации и партнёра.
Роли сотрудников партнёра
- Администратор партнера — PARTNER-ADMIN. Управление предусмотренной частью работы своей компании.
- Модератор партнера — PARTNER-SUPERVISOR. Предусмотренные оперативные и модераторские действия партнёра.
- Поддержка партнера — PARTNER-SUPPORT. Сопровождение относящихся к партнёру обращений.
- Техподдержка партнера — PARTNER-TECHSUPPORT. Предусмотренное техническое сопровождение участия партнёра.
Наличие роли партнёра не даёт доступ ко всем компаниям. Проверки заказа учитывают область компании и действующие Permissions/Relationship. Саму компанию-партнёра нельзя подменять учётной записью её сотрудника.
Участники конкретного заказа
- Создатель — пользователь created_by; факт создания не определяет автоматически плательщика и получателя.
- Клиент — клиентский профиль client. В проверках клиентских ролей используются METASERVICE-CLIENT и CORP-CLIENT; принадлежность к группе не заменяет связь пользователя с конкретным заказом.
- Корпоративный заказчик — corp_client. Действия пользователя от его имени требуют соответствующего контекста представительства.
- Получатель — receiver либо сохранённые в заказе receiver_name/receiver_phone. Получатель может отличаться от создателя и заказчика.
- Исполнитель — METASERVICE-PROVIDER; provider в заказе обозначает профиль предложения исполнителя, а не просто логин. Для действий проверяется назначение и допустимость операции.
- Гость сервиса — METASERVICE-GUEST. Это имя в справочнике, а не универсальный доступ к чужим заказам.
В UI встречаются несколько кодов с одинаковым отображаемым названием клиента, включая METASERVICE-CORPCLIENT и CORP-CLIENT. Не считать их автоматически взаимозаменяемыми: проверять точный код, используемый конкретным обработчиком доступа.
Сервисная компания и роль пользователя
Доход, комиссия, обязанность исполнить договор и расходы при отмене относятся к соответствующей стороне отношений — например, сервисной компании, партнёру или исполнителю. Нельзя приписывать их лично Администратору сервиса лишь потому, что пользователь состоит в METASERVICE-ADMIN. Если сценарий описывает настройку, сопровождение или решение сотрудника, называть конкретную роль; если обязательство компании — называть компанию или сторону договора.
Роль в группе, фактическое разрешение на объект и полномочие действовать от имени компании — разные основания. Членство LDAP/Django не равно действующему business-grant. Relationship описывает связь, Permissions — разрешение; требования и проверки могут влиять на эффективный доступ. Наличие права просмотра заказа не доказывает право изменить цену, обещать компенсацию или отменить оплату.
Контракт историчности
При изменении отношений или увольнении исторические действия должны сохранять прежнего автора, а будущие операции — оценивать текущие полномочия. Это требование к реализации; наличие группы или записи об отношении само по себе не доказывает прохождение всех проверок на установке. Копия удостоверения личности также не создаёт роль участника заказа.