Назначение: Сценарий процесса. Продукт: ShariX Open.
Для кого: Владелец сервиса · Администратор · Поддержка · Разработчик · Нейросеть.
Темы: Сервис → Подключение партнёра · Доступ → Полномочия · Обработчики → NEG_REQUEST.
Навигация: База знаний → Сценарии → Заявка партнёра.
Сценарий описывает регистрацию партнёрского кабинета ShariX Open через CooperateView. Компания, полномочия представителя и договорная связь проходят отдельные проверки. Сообщение об отправке формы не означает завершённой активации всех объектов.
Для доступа нужны:
При отсутствии Metaservice показывается предусмотренная страница необходимости настройки. Скрытый пункт меню не является самостоятельной проверкой прав: допуск проверяет серверный слой.
Сначала проверить показанный список уже существующих партнёрских кабинетов. Новый кабинет создают для нужного юридического лица, а не повторяют форму для ремонта прежней заявки.
Поля компании:
Проверка реквизитов выполняется серверной формой. Например, ИНН должен содержать 10 или 12 цифр; КПП при указании — 9 цифр, а для ИП с 12-значным ИНН не используется. Это техническая валидация ввода, а не подтверждение проверки самой компании.
В auto_roles можно выбрать дополнительные роли:
Обязательные согласия — accept_partner_agreement и accept_client_agent_agreement. Они относятся к показанным документам; отсутствие клиентской ошибки не заменяет серверной проверки согласий.
Внутри transaction.atomic код выполняет следующие шаги:
Типы запросов различаются:
| Объект/результат | Ticket | Что не следует считать завершённым вместе с ним |
|---|---|---|
| Проверка Company | ST_REQUEST активации партнёра | Полномочия и договорное Relationship имеют отдельные запросы. |
| Полномочие пользователя | ACCESS_REQUEST, связанный с Permissions | Членство в группе само по себе не подтверждает активное предметное полномочие. |
| Договорная связь | NEG_REQUEST, связанный с Relationship | Не подменяет ST_REQUEST компании. |
| Связь исполнителя с партнёром | Отдельный NEG_REQUEST при выборе роли исполнителя | Не подменяет ACCESS_REQUEST на METASERVICE-PROVIDER. |
После блока сохранения код отдельно пытается назначить PARTNER-ADMIN и выбранные роли через assign_role_and_refresh. Ошибка этого шага показывается пользователю; затем форма сообщает об отправке заявки. Поэтому сообщение об успехе нужно читать вместе с возможными ошибками назначения.
Helpers ensure_partner_permission_request и _ensure_relationship_request ищут соответствующее активное состояние или открытый PENDING/ACCEPTED-запрос для того же объекта. Это предотвращает часть повторных связанных запросов.
Однако form_valid начинает с нового сохранения Company. Из защиты helper не следует идемпотентность всей отправки формы. После обрыва или неопределённого ответа сначала проверяют, создана ли компания и какие запросы уже существуют. Повтор формы может создать ещё одну компанию.
Для contract Relationship нужен найденный пользователь группы METASERVICE-ADMIN. Его отсутствие вызывает конкретную ошибку подготовки договорной связи; это не решается случайным выбором ID другого пользователя. Реквизиты и остальные необходимые записи проверяют по состоянию установки.
Рассмотрение заявки компании, решение по полномочию и активация Relationship — разные действия. Текущее ограничение ручной ветви NEG_REQUEST описано в PENDING: уведомление и API scope. Его нельзя скрывать общим утверждением «все заявки автоматически обрабатываются».
Полный браузерный сценарий и реальная выдача ролей на сервере при этой source-проверке не выполнялись. Модули и поля сверены с Git; фактическую конфигурацию проверяют отдельно.
Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение состояния сервера или выполнения процесса в установленной системе.
Нормативное уточнение от 31.10.2026, а не сообщение о развёрнутом исправлении. Employee обозначает внутреннюю связь человека с юридическим лицом. Представитель компании, исполнитель, администратор и другие связанные с ней люди могут иметь такую запись. Эта связь остаётся в ведении юридического лица; Сервис или Платформа не должны превращать её наличие в самостоятельный внешний допуск.
LDAP-роль открывает соответствующий интерфейс для подготовки данных, загрузки документов и заполнения полей. Она добавляется при подаче заявки, до окончательного решения. Разрешение на конкретную операцию проверяется отдельно: нужны действующее разрешение нужного вида, соответствующая компания или область действия, установленное внешнее отношение и остальные требования операции. Роль по отношению к одному Сервису не предоставляет права на любую компанию.
Contract обозначает внешнее договорное отношение компании с Сервисом и не заменяет внутренний employee. Участник, не являющийся представителем компании по договору, получает свою область через собственное разрешение; отношение «сам с собой» для этого не требуется. ACCESS_REQUEST и NEG_REQUEST имеют разные предметы и могут идти в разные списки, даже если решения принимает один человек.
Запрос роли Сервиса не должен автоматически создавать внешний NEG_REQUEST(employee). Исторические записи сохраняются: это уточнение не разрешает удалять, автоматически активировать или массово восстанавливать отношения. Подготовленная правка API и проверок должна пройти отдельное применение и runtime-приёмку; эта страница сама по себе не подтверждает состояние серверов.