Исправлена ошибка 'get_object_or_404 is not defined' при попытке
провести оплату через POS-терминал.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Исправлена ошибка 'currentWarehouse is not defined' при проведении продажи.
Добавлен JSON блок currentWarehouseData в template и инициализация
переменной currentWarehouse в terminal.js.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Добавлена интеграция оплаты в POS с поддержкой одиночной и смешанной оплаты,
работой с кошельком клиента и автоматическим созданием заказов.
Backend изменения:
- TransactionService: добавлены методы get_available_payment_methods() и create_multiple_payments()
для фильтрации способов оплаты и атомарного создания нескольких платежей
- POS API: новый endpoint pos_checkout() для создания заказов со статусом "Выполнен"
с обработкой платежей, освобождением блокировок и очисткой корзины
- Template tags: payment_tags.py для получения способов оплаты в шаблонах
Frontend изменения:
- PaymentWidget: переиспользуемый ES6 класс с поддержкой single/mixed режимов,
автоматической валидацией и интеграцией с кошельком клиента
- terminal.html: компактное модальное окно (70vw) с оптимизированной компоновкой,
удален функционал скидок, добавлен показ баланса кошелька
- terminal.js: динамическая загрузка PaymentWidget, интеграция с backend API,
обработка успешной оплаты и ошибок
Поддерживаемые способы оплаты: наличные, карта, онлайн, баланс счёта.
Смешанная оплата позволяет комбинировать несколько способов в одной транзакции.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Заблокировал изменение полей is_positive_end и is_negative_end для
системных статусов заказов, так как эти флаги используются в сигналах
inventory для управления резервированием и списанием товаров со склада.
Что изменено:
- OrderStatusForm: Добавлена блокировка (disabled=True) для полей
is_positive_end и is_negative_end при редактировании системных статусов
- status_form.html: Заменено информационное предупреждение на красное
с детальным описанием заблокированных полей и их влияния на систему
Почему это критично:
Эти флаги проверяются в 3 сигналах inventory/signals.py:
1. rollback_sale_on_status_change - откатывает продажи при уходе от 'completed'
2. release_reservations_on_cancellation - освобождает резервы при отмене
3. reserve_stock_on_uncancellation - резервирует при восстановлении заказа
Случайное изменение флагов может привести к:
- Неправильному освобождению резервов товара
- Двойному резервированию
- Блокировке товара навсегда
- Списанию товара для отмененных заказов
Разрешено редактировать для системных статусов: name, label, color, description
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Удалены из git:
- Скрипты активации и диагностики тенантов
- Тестовые файлы (test_*.py, test_*.txt)
- SQL скрипты для отладки
- Backup файлы (*.backup, *.old)
- Дубликат .gitignore из myproject/
Файлы остались на диске, но теперь игнорируются git.
В репозитории остались только:
- myproject/ (основной код проекта)
- requirements.txt
- .gitignore
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Удалены все файлы .md (30 файлов)
- Добавлена маска *.md в .gitignore для защиты от будущих коммитов
- Причина: .md файлы содержали примеры паролей и внутреннюю документацию
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Реализовано три уровня защиты от доступа владельцев тенантов к /admin/:
1. Явные флаги безопасности в CustomUserManager.create_user()
- Добавлены setdefault(is_staff=False, is_superuser=False)
- Устраняет зависимость от неявных дефолтов Django
2. Явные флаги при создании владельцев тенантов (tenants/admin.py)
- Владельцы создаются с is_staff=False, is_superuser=False
- Явная документация намерений в коде
3. Middleware защита на уровне HTTP (TenantAdminAccessMiddleware)
- Блокирует доступ к /admin/ на поддоменах тенантов
- Только is_superuser=True может войти в админку тенанта
- Последний рубеж обороны (defense-in-depth)
Дополнительно:
- Исправлена видимость alert-уведомлений на странице регистрации
(добавлены явные цвета для всех типов alert)
Суперпользователи НЕ затронуты: create_superuser() работает как прежде.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Исправлена критическая уязвимость безопасности, которая потенциально позволяла
владельцам тенантов получить доступ к админ-панели Django.
Изменения:
- Добавлены явные setdefault для is_staff=False и is_superuser=False в CustomUserManager.create_user()
- Добавлены явные флаги безопасности при создании владельца тенанта
- Добавлены явные флаги безопасности при создании пользователей через систему ролей
- Создан TenantAdminAccessMiddleware для защиты /admin/ на уровне middleware
- Создана миграция данных для исправления флагов у существующих пользователей
Реализована трёхуровневая защита (Defense-in-Depth):
1. Уровень модели: явные дефолты в create_user()
2. Уровень views: явные флаги при создании
3. Уровень middleware: runtime блокировка доступа
Файлы:
- accounts/models.py: явные флаги в create_user()
- tenants/admin.py: явные флаги при создании владельца
- user_roles/views.py: явные флаги при создании через роли
- myproject/admin_access_middleware.py: новый middleware
- myproject/settings.py: регистрация middleware
- accounts/migrations/0002_fix_owner_staff_flags.py: миграция данных
ВАЖНО: После применения этого коммита необходимо выполнить:
1. python manage.py migrate accounts
2. python manage.py migrate_schemas
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Protect owners from accidentally locking themselves out by:
- Adding RoleService.can_modify_user_role() to centralize validation logic
- Blocking edit/delete operations on own role in views
- Hiding edit/delete buttons for own role in template
This prevents owners from:
- Changing their own role to a lower privilege level
- Deactivating themselves
- Deleting their own access
Standard admin pattern used by GitHub, WordPress, Django Admin.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add view mixins (RoleRequiredMixin, OwnerRequiredMixin, ManagerOwnerRequiredMixin) to user_roles/mixins.py
- Replace PermissionRequiredMixin with ManagerOwnerRequiredMixin in all product views
- Remove permission_required attributes from view classes
- Owner and Manager roles now grant access without Django model permissions
This allows owners to access all product functionality through their custom role,
without needing to be superusers or have explicit Django permissions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Added get_user_model import in accounts/views.py
- Fixed User variable scope in password_setup_confirm view
- Added accounts URLs to urls_public.py for password setup on main domain
- Password setup link now accessible from public schema
Technical details:
- get_user_model() needed to be imported from django.contrib.auth
- User model reference moved outside try block to fix UnboundLocalError
- accounts.urls included in public URLconf for /accounts/setup-password/ route
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Fixed UnboundLocalError by importing RoleService before use
- Changed action buttons to vertical stack layout to prevent overlap
- Buttons now use flexbox column layout with proper spacing
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added save_model override to TenantRegistrationAdmin to catch status
changes from PENDING to APPROVED and trigger the full activation flow.
Previously, changing status via admin form only saved the status field
without creating the tenant, sending emails, etc.
Now both methods work:
- Click "Activate" button (via GET parameter)
- Change status dropdown and save (via save_model)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
When admin approves tenant registration:
- Owner account created in tenant schema (in addition to admin@localhost)
- Owner assigned 'owner' role with full permissions
- Password setup email sent with secure 7-day token link
- Owner sets password via link and auto-logs into their shop
Key changes:
- Added password_setup_token fields to TenantRegistration model
- Created tenants/services.py with formatted email service
- Modified _approve_registration to create owner account
- Added password_setup_confirm view with token validation
- Created password setup template and URL route
- Added admin action to resend password setup emails
Security:
- Token expires after 7 days
- Password not transmitted in email (secure setup link)
- Owner account inactive until password set
- Admin@localhost preserved for system administrator access
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Added role management views (list, create, edit, delete)
- Created user_roles URL routing
- Added role management templates with Bootstrap styling
- Updated navbar with Roles link for owners and superusers
- Enhanced decorators and mixins with superuser bypass
- Added assign_owner_role.py utility script
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Добавлена система ролей пользователей для управления доступом в multi-tenant приложении.
Новые роли:
- Владелец (Owner): полный доступ, управление пользователями
- Менеджер (Manager): управление заказами, клиентами, товарами, складом
- Флорист (Florist): работа с заказами и складскими операциями
- Курьер (Courier): роль создана, права будут определены позже
Архитектура:
- Роли автоматически изолируются по тенантам через django-tenants (TENANT_APPS)
- Не требуется FK на Client/Tenant - изоляция через PostgreSQL schemas
- Роли автоматически создаются при создании нового тенанта
Компоненты:
- user_roles/models.py: модели Role и UserRole
- user_roles/services.py: RoleService для управления ролями
- user_roles/decorators.py: @role_required, @owner_required
- user_roles/mixins.py: RoleBasedAdminMixin, OwnerOnlyAdminMixin
- user_roles/admin.py: админка для управления ролями
- user_roles/management/commands/init_roles.py: команда для инициализации
Изменения:
- accounts/models.py: добавлены helper методы (is_owner, has_role, etc)
- settings.py: добавлен user_roles в TENANT_APPS
- tenants/admin.py: автосоздание ролей при создании тенанта
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The cleanup_draft_orders command was no longer needed in the project.
Also updated test output file with latest test results.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Added all real order statuses: new, confirmed, in_assembly, in_delivery, return
- Test #2: expanded to test cancellation from 4 different statuses (new, confirmed, in_assembly, in_delivery)
- Test #3: updated to use new → cancelled → in_assembly flow
- Test #4: updated to use in_delivery status instead of packing
- All 5 tests passing successfully
Проблема:
- Поле OrderStatus.color имеет max_length=7 (для hex типа #FF5733)
- В тестах использовались названия: 'secondary', 'warning', 'success' (9 символов)
- PostgreSQL выдавал ошибку: value too long for type character varying(7)
Решение:
- Заменены названия цветов на hex коды:
* 'secondary' → '#9E9E9E' (серый)
* 'warning' → '#FF9800' (оранжевый)
* 'success' → '#4CAF50' (зелёный)
* 'danger' → '#F44336' (красный)
* 'info' → '#17A2B8' (голубой)
Tests cover:
1. Multiple status transitions (draft->completed->cancelled->completed)
2. Cancellation from draft (reservation release)
3. Un-cancellation to pending (reservation restore)
4. Creating order with intermediate status
5. Rollback from completed to draft
Each test verifies:
- Stock state (available, reserved, free)
- Reservation status transitions
- Sale creation/deletion without duplicates
- StockBatch quantity changes
Files:
- inventory/tests/test_order_status_transitions.py (570 lines)
- inventory/tests/README.md (138 lines)
- inventory/tests/__init__.py
- run_status_tests.bat (launch script)
Проблема:
- Поиск товаров возвращал пустые результаты
- API /products/api/search-products-variants/ возвращает ID в формате 'product_123'
- Форма incoming ожидает числовой ID (123)
- Select2 не мог сохранить значение из-за несовпадения формата
Решение:
- Добавлена функция processResults в AJAX настройках Select2
- Извлекаем числовой ID из строки 'product_123' -> '123'
- Обрабатываем как группированные результаты, так и плоские
- Сохраняем остальные поля (text, sku, price, actual_price)
Логика обработки:
1. Проверяем наличие children (группа)
2. Если группа - обрабатываем каждый item в children
3. Если плоский список - обрабатываем напрямую
4. Используем .replace('product_', '') для извлечения ID
Теперь Select2 корректно:
- Показывает список товаров
- Сохраняет выбранное значение
- Отправляет числовой ID в форму
Проблема:
- На странице /inventory/incoming/create/ не работал поиск товаров
- Использовался обычный <select> с предзагруженным списком всех товаров
- При большом количестве товаров список был неудобным
- Невозможно было искать товары по названию в реальном времени
Решение:
- Заменён обычный <select> на Select2 с AJAX автокомплитом
- Подключен API endpoint /products/api/search-products-variants/
- Поиск товаров работает в реальном времени (с задержкой 250ms)
- Минимальная длина поиска: 0 символов (можно открыть весь список)
- Поддержка русского языка
- Theme: bootstrap-5 для визуального соответствия
Изменения:
- Удалён предзагруженный список товаров из контекста шаблона
- Добавлена инициализация Select2 для каждой новой строки товара
- При удалении строки вызывается select2('destroy') для очистки
- Исправлена логика восстановления товаров при ошибке валидации
- Используется Option API для программной установки значений
Технические детали:
- jQuery и Select2 уже подключены в base.html
- Не дублируем подключение библиотек
- Используем событие 'change' для Select2 вместо 'input'
- Кэширование AJAX запросов включено
Теперь поиск товаров работает корректно! 🎉
Проблема:
- При изменении количества в OrderItem для заказа в статусе 'completed'
- Создавался ДУБЛИКАТ резерва (старый converted_to_sale + новый reserved)
- Это приводило к двойному списанию товара со склада (-10 лишних единиц)
- Фильтр status='reserved' пропускал существующие резервы в других статусах
Сценарий бага:
1. Заказ выполнен: 20 шт → резерв 20 шт (converted_to_sale)
2. Увеличить на 10 шт (до 30) → создаётся НОВЫЙ резерв 30 шт (reserved)
3. Итого: 20 + 30 = 50 шт зарезервировано вместо 30!
4. При переводе обратно в 'completed' → двойное списание (50 вместо 30)
Решение:
- Убран фильтр status='reserved' из update_reservation_on_item_change
- Теперь резерв ищется по order_item независимо от статуса
- Обновляется ТОЛЬКО quantity, статус НЕ меняется
- Добавлен @transaction.atomic для атомарности операции
- Добавлено логирование всех операций с резервами
- Используется save(update_fields=['quantity']) для оптимизации
Безопасность решения:
- Резервы разных заказов НЕ конфликтуют (разные order_item)
- Один товар в разных заказах = разные OrderItem = разные Reservation
- Каждый OrderItem имеет уникальный резерв
- Дубликаты больше НЕ создаются
Изменённые файлы:
- inventory/signals.py (функция update_reservation_on_item_change)
- FIX_RESERVATION_DUPLICATE_BUG.md (полная документация бага и решения)
Покрытие всех сценариев:
✅ Создание заказа с товарами
✅ Добавление товара при редактировании
✅ Изменение количества (черновик)
✅ Изменение количества (выполнен) - ИСПРАВЛЕНО
✅ Повторное сохранение заказа
КРИТИЧНО: Это исправление влияет на учёт товара и требует тестирования!
Проблема:
- Фильтр по заказу не работал
- order_number в форме передается как строка (ORD-103 или 103)
- В модели Order поле order_number имеет тип PositiveIntegerField
- Не было преобразования строки в число
Исправление:
- Добавлен парсинг номера заказа:
* Если формат 'ORD-103' -> извлекается число 103
* Если просто '103' -> преобразуется в число 103
- Добавлена обработка ошибок (try-except)
- Добавлена фильтрация таблицы заказов (показывать только выбранный)
Теперь фильтр работает с любым форматом ввода:
- ORD-103 ✓
- ord-103 ✓
- 103 ✓
Проблема:
- В шаблоне использовалось несуществующее поле total_price
- Фактическое поле в модели Order называется total_amount
Исправление:
- Заменено order.total_price на order.total_amount
- Теперь итоговая сумма заказа отображается корректно
Проблема:
- В шаблоне использовалось несуществующее поле cost_per_unit
- Фактическое поле в модели StockBatch называется cost_price
Исправление:
- Заменено batch.cost_per_unit на batch.cost_price
- Теперь закупочная цена партии отображается корректно
Проблема:
- В шаблоне использовалось несуществующее поле cost_per_unit
- Фактическое поле в модели называется cost_price
Исправление:
- Заменено alloc.cost_per_unit на alloc.cost_price
- Теперь себестоимость за единицу отображается корректно
