Создан TenantOnboardingService как единый источник истины для:
- Активации заявки на регистрацию тенанта
- Создания Client, Domain, Subscription
- Инициализации системных данных (Customer, статусы, способы оплаты, склад, витрина)
Новые сервисы:
- TenantOnboardingService (tenants/services/onboarding.py)
- WarehouseService (inventory/services/warehouse_service.py)
- ShowcaseService (inventory/services/showcase_service.py)
- PaymentMethodService (orders/services/payment_method_service.py)
Рефакторинг:
- admin.py: 220 строк → 5 строк (делегирование сервису)
- init_tenant_data.py: 259 строк → 68 строк
- activate_registration.py: использует сервис
- Тесты обновлены для вызова сервиса напрямую
При создании тенанта автоматически создаются склад и витрина по умолчанию.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Проблема:
- При смене статуса заказа на 'Выполнен' товар списывался со склада
- Резервы обновлялись на статус 'converted_to_sale'
- НО Stock.quantity_reserved не обновлялся автоматически
- В результате резервы продолжали 'держать' товар, хотя он уже продан
Решение:
1. Изменен сигнал create_sale_on_order_completion:
- Используется .save(update_fields=[...]) вместо .update()
- Это вызывает сигнал update_stock_on_reservation_change
- Убран костыль с ручным вызовом refresh_from_batches()
2. Оптимизирован сигнал update_stock_on_reservation_change:
- Stock обновляется ТОЛЬКО при изменении status или quantity
- При изменении других полей (даты и т.д.) Stock НЕ пересчитывается
- Предотвращены лишние пересчёты и улучшена производительность
3. Добавлены диагностические инструменты:
- check_stock_103.py - для диагностики проблем с Stock
- fix_stock_after_sale.py - команда для исправления старых заказов
- diagnose_reservation_issue.py - универсальная диагностика
Результат:
- Элегантное решение без дублирования логики
- Stock автоматически обновляется при изменении резервов
- Работает везде, не только в заказах
- Оптимизировано для производительности
Создан файл tenants/tests/test_tenant_creation.py с 7 E2E тестами:
1. test_new_tenant_gets_all_5_payment_methods (КРИТИЧЕСКИЙ)
- Проверяет что новый тенант получает все 5 способов оплаты
- Включая account_balance (основной баг который исправили)
- Проверяет правильность порядка, флагов, названий
2. test_new_tenant_gets_order_statuses
- Проверяет создание системных статусов заказов
- Минимум 3 статуса (draft, completed и другие)
3. test_new_tenant_gets_system_customer
- Проверяет создание системного клиента
- Для анонимных продаж
4. test_new_tenant_gets_superuser
- Проверяет создание суперпользователя
- С email из настроек TENANT_ADMIN_EMAIL
5. test_new_tenant_gets_domain
- Проверяет создание домена
- Формат: {schema_name}.localhost
6. test_registration_status_changes_to_approved
- Проверяет изменение статуса заявки
- PENDING → APPROVED
7. test_complete_tenant_onboarding (КОМПЛЕКСНЫЙ E2E)
- Проверяет весь процесс онбординга
- Все предыдущие проверки в одном тесте
- Красивый вывод результата в консоль
Особенности:
- TransactionTestCase для работы с реальными схемами
- Создание администратора в setUp для каждого теста
- Автоматическая очистка схем в tearDown
- Вызов реального метода _approve_registration из админки
- Полное тестирование процесса как в продакшене
Результат: 2 главных теста прошли успешно ✓
test_new_tenant_gets_all_5_payment_methods: OK (10s)
test_complete_tenant_onboarding: OK (9.5s)
