Backend/dbsynce: синхронизируемые сущности

Назначение: Справка по компоненту. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Интегратор · Нейросеть.

Темы: Архитектура → Владение моделями · API → Контракты · Доступ → Объектные права.

Репозиторий sharix-open-backend устанавливается в сборку как dbsynce. Он владеет общими данными ShariX Open и операциями над ними. Название каталога dbsynce не означает, что модуль только копирует чужие таблицы: здесь определены собственные модели, проверки и API.

Какие данные искать здесь

Модель	Что обозначает	С чем не смешивать
Company	Компанию — участника сервиса, её представителя и состояние проверки.	Учётная запись представителя не является самой компанией.
ServiceCategory	Категорию услуги и её общие правила.	Конкретное предложение компании хранится отдельно.
Service	Спецификацию/тариф предложения с компанией и категорией.	Это не весь развёрнутый сервис и не отдельный заказ.
Provider	Предложение исполнителя, связанное с user, Service, Company и, когда требуется, Resource.	Один пользователь может иметь несколько предложений; user.pk не заменяет provider.pk.
Client и CorpClient	Клиентский профиль и корпоративного заказчика.	Они не заменяют created_by или receiver заказа.
Orders	Конкретный заказ, его условия, участников и связь с Ticket.	Локальное расширение и план этапов принадлежат другим моделям.
Documents и DocumentVersion	Общие документы и их версии.	Файл, документ и бизнес-проверка документа имеют разные роли.
Permissions, Relationship, RequirementCheck	Предметные права/отношения и сохранённые проверки требований.	Наличие общей роли пользователя не заменяет проверку нужного объекта и условия.

Точный экспорт находится в models/init.py. Для изменения сущности читают:

Соответствующий models/*.py.
Serializer сущности.
View.
Вызывающую операцию.
Миграции.

Например, путь заказа продолжается в:

lib/open_order_api.py;
lib/order_actions.py;
lib/order_permissions.py.

Область метасервиса и права пользователя

В сборке ShariX Open включён DBSYNCE_METASERVICE_SCOPE_ENABLED. Для моделей на основе MetaserviceScopedModel менеджер objects ограничивает выборку текущим METASERVICE_ID; при сохранении новой записи область назначается, а изменение чужой записи отклоняется. Настройку читает lib/metaservice_scope.py. Значение 0 допустимо как демонстрационная область; отсутствие или неверный формат при включённом ограничении — ошибка конфигурации.

Это ограничение не заменяет права пользователя. Два заказа в одной области всё ещё могут принадлежать разным клиентам. При отборе заказов:

использовать предметный отбор get_orders_queryset_for_user из lib/order_permissions.py;
не заменять его обычным Orders.objects.all() в публичном списке.

Менеджер all_objects существует для специальных обслуживающих операций. Его нельзя выбирать в обычной форме или API только потому, что нужная запись не находится через objects: сначала проверяют область, идентификатор и основание доступа.

Общий backend и локальное исполнение

Общие условия заказа остаются в Orders. Особенности локального сервиса размещаются в его расширении. OrderExecution, Stage и Artifact определены в webservice_running, а не переносятся в backend из-за того, что их часто показывает общая карточка заказа.

Для исполнения backend предоставляет нейтральные функции в lib/integration_ports.py, в частности initialize_order_execution. Адаптер регистрирует использующий его слой. Backend не должен импортировать локальный runtime или закрытый конструктор, чтобы сохранить базовую запись заказа. Отсутствие адаптера имеет явный результат; оно не должно маскироваться выдуманным успешным исполнением.

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

В ShariX Open корневой маршрут dbsynce/ подключает dbsynce.urls. При DBSYNCE_OPEN_API_ENABLED подключается API v1 из apiviews/open_api.py. Конкретный пользовательский путь заказа — /dbsynce/api/v1/orders/. Важно прочитать permission_classes, выборку и предметную операцию: само наличие маршрута не доказывает право создавать или читать любой заказ.

Нужно различать операции:

создание заказа;
ручное действие;
получение снимка заказа;
синхронизацию.

Обычный повтор POST после таймаута не становится безопасным только из-за существования модели интеграционного запроса. Публичный клиентский сценарий описан в создании заказа.

Как выбирать место изменения

Если меняется смысл общего поля или правила заказа, определить владельца в backend и потребителей изменения.
Если поле описывает только локальную работу сервиса, проверить существующее расширение в webservice_running.
При новой операции сохранить предметную проверку доступа, а не только проверку входа пользователя.
Если меняется схема, подготовить миграцию в репозитории владельца и проверить переход существующей базы. Не генерировать её на рабочем сервере ради устранения drift.
Проверить сценарий с допустимым объектом и отказ с чужим объектом; зафиксировать фактически выполненное.

Подробности — владение моделями, API-контракты и приёмка изменений.

Лицензия и другие потребители

У проверенного sharix-open-backend — GNU AGPL v3; условия выбранной версии сверяют в LICENSE и COMPLIANCE. Общий backend может использоваться Platform, поэтому после публикации shared-изменения нужно оповестить её ответственного и передать commits, совместимость и результаты проверок. Внутренние схемы Platform и порядок её обновления находятся в intrawiki.

Закрытый компонент, установленный рядом с ShariX Open, не становится открытым backend. Его название и границу можно указать публично; детали получают у ответственных Platform. Ни слово shared, ни доступ к исходникам не заменяют проверку лицензии.

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

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

Содержание