Подача и обработка заявки партнёра

Назначение: Сценарий процесса. Продукт: ShariX Open.

Для кого: Владелец сервиса · Администратор · Поддержка · Разработчик · Нейросеть.

Темы: Сервис → Подключение партнёра · Доступ → Полномочия · Обработчики → NEG_REQUEST.

Навигация: База знаний → Сценарии → Заявка партнёра.

Сценарий описывает регистрацию партнёрского кабинета ShariX Open через CooperateView. Компания, полномочия представителя и договорная связь проходят отдельные проверки. Сообщение об отправке формы не означает завершённой активации всех объектов.

Где находится вход

Маршрут: sharix_admin:cooperate_request, локальный путь cooperate-request/.
Префикс кабинета: определяется SHARIX_ADMIN_PATH в URL-конфигурации установки; фиксированный адрес для всех установок здесь не задаётся.
View: sharix_admin/views/cooperate.py, класс CooperateView.
Форма: sharix_admin/forms/company.py, CooperateCompanyForm.
Общие запросы: dbsynce/lib/partner_requests.py и dbsynce/lib/ticket_gen.py.

Для доступа нужны:

вход в учётную запись;
разрешённый режим ALLOW_PARTNER_REQUEST;
доступ по ключу страницы cooperate_request;
существующий контекст Metaservice.

При отсутствии Metaservice показывается предусмотренная страница необходимости настройки. Скрытый пункт меню не является самостоятельной проверкой прав: допуск проверяет серверный слой.

Что заполняет заявитель

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

Поля компании:

legal_name — наименование;
inn — ИНН;
kpp — КПП;
ogrn — ОГРН;
bank_name — банк;
bik — БИК;
rs — расчётный счёт;
ks — корреспондентский счёт;
address — адрес;
tax_method — система налогообложения.

Проверка реквизитов выполняется серверной формой. Например, ИНН должен содержать 10 или 12 цифр; КПП при указании — 9 цифр, а для ИП с 12-значным ИНН не используется. Это техническая валидация ввода, а не подтверждение проверки самой компании.

В auto_roles можно выбрать дополнительные роли:

PARTNER-SUPERVISOR;
PARTNER-SUPPORT;
PARTNER-TECHSUPPORT;
METASERVICE-PROVIDER.

Обязательные согласия — accept_partner_agreement и accept_client_agent_agreement. Они относятся к показанным документам; отсутствие клиентской ошибки не заменяет серверной проверки согласий.

Какие записи создаются

Внутри transaction.atomic код выполняет следующие шаги:

Сохраняет Company с repr текущего пользователя и первоначальным статусом deactivated.
Создаёт ST_REQUEST активации компании и сохраняет ссылку Company.ticket_status.
Обеспечивает запрос полномочия PARTNER-ADMIN.
Обеспечивает дополнительные запросы полномочий для выбранных auto_roles.
Исторический код при METASERVICE-PROVIDER отдельно создавал employee Relationship с NEG_REQUEST; по уточнению владельца ниже этот шаг не является внешним условием допуска и удаляется подготовленной правкой.
Обеспечивает contract Relationship с собственным NEG_REQUEST.
Вызывает предусмотренные действия по требованиям для созданных объектов.

Типы запросов различаются:

Объект/результат	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 другого пользователя. Реквизиты и остальные необходимые записи проверяют по состоянию установки.

Что проверяет ответственный

Представителя и реквизиты созданной Company.
Статус Company и связанный ST_REQUEST.
Каждое Permissions и его ACCESS_REQUEST.
Contract Relationship и соответствующий NEG_REQUEST.
Исторический Employee Relationship при выборе роли исполнителя; не считать самостоятельным внешним допуском.
Требования и результаты их проверки.
Членство пользователя в нужных группах и обновлённый контекст доступа.
Доступность нужного кабинета под учётной записью заявителя.

Рассмотрение заявки компании, решение по полномочию и активация Relationship — разные действия. Текущее ограничение ручной ветви NEG_REQUEST описано в PENDING: уведомление и API scope. Его нельзя скрывать общим утверждением «все заявки автоматически обрабатываются».

Отказ и восстановление

Ошибка поля или согласия: исправить указанный ввод в форме.
Недоступна страница: проверить вход, ALLOW_PARTNER_REQUEST, доступ к странице и Metaservice.
Ошибка назначения роли: проверить уже сохранённые объекты и состояние групп/каталога учётных записей; не начинать с повторной отправки формы.
Неизвестен результат отправки: установить наличие Company и связанных запросов до повторного создания.
Запрос существует, но результат не достигнут: определить конкретный тип, статус и обработчик, а не вручную активировать все сущности сразу.

Полный браузерный сценарий и реальная выдача ролей на сервере при этой source-проверке не выполнялись. Модули и поля сверены с Git; фактическую конфигурацию проверяют отдельно.

Связанные материалы

Исходники, сверенные 31.10.2026

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение состояния сервера или выполнения процесса в установленной системе.

Уточнение владельца: внутренняя связь employee и внешний допуск

Нормативное уточнение от 31.10.2026, а не сообщение о развёрнутом исправлении. Employee обозначает внутреннюю связь человека с юридическим лицом. Представитель компании, исполнитель, администратор и другие связанные с ней люди могут иметь такую запись. Эта связь остаётся в ведении юридического лица; Сервис или Платформа не должны превращать её наличие в самостоятельный внешний допуск.

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

Contract обозначает внешнее договорное отношение компании с Сервисом и не заменяет внутренний employee. Участник, не являющийся представителем компании по договору, получает свою область через собственное разрешение; отношение «сам с собой» для этого не требуется. ACCESS_REQUEST и NEG_REQUEST имеют разные предметы и могут идти в разные списки, даже если решения принимает один человек.

Запрос роли Сервиса не должен автоматически создавать внешний NEG_REQUEST(employee). Исторические записи сохраняются: это уточнение не разрешает удалять, автоматически активировать или массово восстанавливать отношения. Подготовленная правка API и проверок должна пройти отдельное применение и runtime-приёмку; эта страница сама по себе не подтверждает состояние серверов.