Project-Pro/orderPRO
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Jacek Pyziak
2026-03-31 00:30:50 +02:00
parent 5435209b08
commit af48e84449
30 changed files with 2706 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
DOCS/ARCHITECTURE.md
View File

@@ -5,7 +5,8 @@
- UI korzysta z globalnego standardu naglowkow sekcji (`h2/h3/h4.section-title`) definiowanego centralnie w `resources/scss/app.scss` i buildowanego do `public/assets/css/app.css`.
- Kolory akcji UI (przyciski `btn--primary` i warianty `btn--outline-primary`) sa odseparowane od koloru naglowkow (`section-title`) przez dedykowane tokeny `--c-action-primary` i `--c-action-primary-dark` w `resources/scss/shared/_ui-components.scss`.
- Import Allegro zapisuje log `import` z kontekstem triggera (`manual_import`, `orders_sync`, `status_sync`) i deduplikuje powtarzalne wpisy bez realnej zmiany.
- Automatyzacja obsluguje zdarzenia `shipment.created` (natychmiast po utworzeniu paczki) i `shipment.status_changed` (po realnej zmianie statusu dostawy), oraz warunek `shipment_status` oparty o statusy biznesowe.
- Automatyzacja obsluguje zdarzenia `shipment.created` (natychmiast po utworzeniu paczki), `shipment.status_changed` (po realnej zmianie statusu dostawy), `payment.status_changed` (po zmianie statusu platnosci — reczne dodanie lub cron sync shopPRO), `order.status_changed` (po zmianie statusu zamowienia — reczna zmiana lub chain z akcji automatyzacji), oraz `order.status_aged` (cron co 1h — zamowienie w danym statusie od X dni).
- Automatyzacja obsluguje warunek `shipment_status` oparty o statusy biznesowe, warunek `payment_status` (0=nieoplacone, 1=czesciowo oplacone, 2=oplacone), warunek `order_status` (kody aktywnych statusow zamowien z `order_statuses`), oraz warunek `days_in_status` (pole numeryczne, ewaluacja >=).
- Automatyzacja obsluguje akcje `issue_receipt` (Wystaw paragon) z parametrami: `receipt_config_id`, `issue_date_mode`, `duplicate_policy`.
- Automatyzacja obsluguje akcje `update_shipment_status` (Zmiana statusu przesylki) z parametrem `status_key` mapowanym na techniczny `delivery_status`.
- Automatyzacja obsluguje akcje `update_order_status` (Zmiana statusu zamowienia) z parametrem `status_code` (aktywny kod z `order_statuses`).

4
DOCS/DB_SCHEMA.md
View File

@@ -226,8 +226,8 @@ Migracje z prefiksem `ensure_` to migracje kompensujące — zostały dodane
### `order_payments`
- Platnosci zamowien (z importu API lub reczne).
- Kolumny:
- `id` (PK, bigint unsigned, AI),
- `order_id` (bigint unsigned, FK -> `orders.id`, CASCADE),
- `id` (PK, int unsigned, AI),
- `order_id` (int unsigned, FK -> `orders.id`, CASCADE),
- `source_payment_id` (varchar 64, nullable),
- `external_payment_id` (varchar 64, nullable),
- `payment_type_id` (varchar 64, NOT NULL) — typ: ONLINE, TRANSFER, CASH_ON_DELIVERY,

34
DOCS/TECH_CHANGELOG.md
View File

@@ -1,5 +1,39 @@
# Tech Changelog
## 2026-03-31 (Phase 60 - Order Status Aged Event, Plan 01)
- Migracja `20260331_000074_seed_order_status_aged_cron.sql`: seed cron schedule `order_status_aged` co 3600s.
- `OrderStatusAgedService`: skanuje zamowienia w danym statusie od X dni (query HAVING MAX(changed_at) na `order_status_history`), limit 100/regule, trigger `order.status_aged`.
- `OrderStatusAgedHandler`: cron handler delegujacy do `OrderStatusAgedService::scan()`.
- `CronHandlerFactory`: rejestracja handlera `order_status_aged`.
- `AutomationController`: dodano `order.status_aged` do `ALLOWED_EVENTS`, `days_in_status` do `ALLOWED_CONDITION_TYPES`, `parseConditionValue` + branch `days_in_status`.
- `AutomationService::evaluateDaysInStatusCondition()`: ewaluacja `context.days_in_status >= value.days`.
- `resources/views/automation/form.php`: opcja "Minelo X dni od zmiany statusu" w zdarzeniach, "Liczba dni w statusie" w warunkach z polem numerycznym.
- `public/assets/js/modules/automation-form.js`: `buildDaysInStatusInput()`, opcja `days_in_status` w `addCondition()` i `onConditionTypeChange()`.
## 2026-03-31 (Phase 59 - Order Status Automation Event, Plan 01)
- `AutomationController`: dodano `order.status_changed` do `ALLOWED_EVENTS`, `order_status` do `ALLOWED_CONDITION_TYPES`, `parseConditionValue` + branch `order_status` (walidacja kodow vs DB), `buildRuleFromRequest` + branch `order_status`.
- `AutomationService::evaluateOrderStatusCondition()`: ewaluacja warunku order_status — porownanie `new_status` z context vs dozwolone `order_status_codes`.
- `AutomationService::handleUpdateOrderStatus()`: pobiera old_status przed zmiana, emituje chain event `order.status_changed` przez `emitEvent()` (tylko przy realnej zmianie statusu).
- `OrdersController::changeStatus()`: pobiera old_status przed `updateOrderStatus()`, emisja `order.status_changed` po udanej zmianie (try/catch, non-blocking).
- `resources/views/automation/form.php`: opcja "Zmiana statusu zamowienia" w zdarzeniach, "Status zamowienia" w warunkach z checkboxami aktywnych statusow.
- `resources/views/automation/index.php`: dodano etykiety `payment.status_changed` i `order.status_changed` do `$eventLabels`.
- `public/assets/js/modules/automation-form.js`: `buildOrderStatusCheckboxes()`, opcja `order_status` w `addCondition()` i `onConditionTypeChange()`.
## 2026-03-30 (Phase 58 - Automation Form Preserve, Plan 01)
- `AutomationController::store()` i `update()`: re-render formularza z danymi z request zamiast redirect przy bledzie walidacji.
- `AutomationController::buildRuleFromRequest()`: buduje tablice `$rule` z POST data w formacie oczekiwanym przez `form.php`.
- `AutomationController::renderForm()`: nowy parametr `$errorMessage` — priorytet nad Flash.
- `resources/views/automation/form.php`: `$isEdit` sprawdza `isset($rule['id'])` (nie `$rule !== null`), conditions/actions wyciagane z `$rule` niezaleznie od `$isEdit`.
## 2026-03-30 (Phase 57 - Payment Automation Event, Plan 01)
- `AutomationController`: dodano `payment.status_changed` do `ALLOWED_EVENTS`, `payment_status` do `ALLOWED_CONDITION_TYPES`, stala `PAYMENT_STATUS_OPTIONS` (0/1/2), parseConditions dla `payment_status_keys`.
- `AutomationService::evaluatePaymentStatusCondition()`: ewaluacja warunku payment_status — porownanie `new_payment_status` z context vs dozwolone status_keys.
- `OrdersController::addPayment()`: emisja `payment.status_changed` po zapisie platnosci (try/catch, non-blocking).
- `ShopproPaymentStatusSyncService::syncSingleOrderPayment()`: emisja `payment.status_changed` po zmianie payment_status w cron sync (tylko przy realnej zmianie).
- `CronHandlerFactory`: przeniesiono tworzenie `$automationService` przed `$shopproPaymentSyncService`, przekazano jako zależność.
- `resources/views/automation/form.php`: opcja "Zmiana statusu platnosci" w zdarzeniach, "Status platnosci" w warunkach z checkboxami (Nieoplacone/Czesciowo oplacone/Oplacone).
- `public/assets/js/modules/automation-form.js`: `buildPaymentStatusCheckboxes()`, opcja w `addCondition()` i `onConditionTypeChange()`.
## 2026-03-30 (Phase 56 - Order Payments, Plan 01)
- Migracja `20260330_000073_create_order_payments_table.sql`: tabela `order_payments` (id, order_id, source_payment_id, external_payment_id, payment_type_id, payment_date, amount, currency, comment, payload_json) + idempotentne dodanie kolumn `total_with_tax`, `total_paid`, `external_payment_type_id` do `orders`.
- `OrdersRepository::addPayment()`: INSERT do `order_payments`, przeliczenie `total_paid` i `payment_status` na `orders`.