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-28 15:04:35 +01:00
parent c1d0d7762f
commit 2ab0d0e90e
44 changed files with 3027 additions and 493 deletions
Download Patch File Download Diff File Expand all files Collapse all files

251
.paul/phases/49-automation-history-tab/49-01-PLAN.md Normal file
View File

@@ -0,0 +1,251 @@
---
phase: 49-automation-history-tab
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
- database/migrations/20260328_000072_create_automation_execution_logs_table.sql
- src/Modules/Automation/AutomationExecutionLogRepository.php
- src/Modules/Automation/AutomationRepository.php
- src/Modules/Automation/AutomationService.php
- src/Modules/Automation/AutomationController.php
- resources/views/automation/form.php
- public/assets/js/modules/automation-form.js
- resources/views/automation/index.php
- resources/scss/modules/_automation.scss
- public/assets/css/app.css
- src/Modules/Cron/CronHandlerFactory.php
- src/Modules/Cron/AutomationHistoryCleanupHandler.php
- routes/web.php
- DOCS/DB_SCHEMA.md
- DOCS/ARCHITECTURE.md
- DOCS/TECH_CHANGELOG.md
autonomous: false
---
<objective>
## Goal
Rozdzielic ekran `/settings/automation` na dwa taby: `Ustawienia` (obecna lista i zarzadzanie regulami) oraz `Historia` (log wykonan automatyzacji z filtrami i paginacja), oraz dodac nowa akcje automatyzacji `zmien status zamowienia` z wyborem statusu docelowego.
## Purpose
Operator musi widziec kiedy i na jakim zamowieniu uruchomila sie automatyzacja (audyt) oraz miec mozliwosc automatycznej zmiany statusu zamowienia przez regule bez recznej ingerencji.
## Output
Nowa historia wykonan automatyzacji zapisywana w dedykowanej tabeli, UI historii w tabie `Historia` z filtrowaniem i paginacja, automatyczne czyszczenie wpisow starszych niz 30 dni oraz nowa akcja reguly `update_order_status` w formularzu automatyzacji.
</objective>
<context>
## Project Context
@.paul/PROJECT.md
@.paul/ROADMAP.md
@.paul/STATE.md
@DOCS/DB_SCHEMA.md
@DOCS/ARCHITECTURE.md
## Prior Work (only if genuinely needed)
@.paul/phases/16-automated-tasks/16-02-SUMMARY.md
@.paul/phases/47-shipment-created-automation/47-01-SUMMARY.md
## Source Files
@src/Modules/Automation/AutomationController.php
@src/Modules/Automation/AutomationRepository.php
@src/Modules/Automation/AutomationService.php
@resources/views/automation/form.php
@public/assets/js/modules/automation-form.js
@resources/views/automation/index.php
@resources/scss/modules/_automation.scss
@src/Modules/Cron/CronHandlerFactory.php
@src/Modules/Cron/CronRepository.php
@resources/views/settings/cron.php
@routes/web.php
</context>
<skills>
## Required Skills (from SPECIAL-FLOWS.md)
| Skill | Priority | When to Invoke | Loaded? |
|-------|----------|----------------|---------|
| `sonar-scanner` | required | Po APPLY, przed UNIFY | o |
| /frontend-design | optional | Przy dopracowaniu ukladu tabow i tabeli historii | o |
| /code-review | optional | Po APPLY, przed UNIFY | o |
**BLOCKING:** Required skills MUST be loaded before APPLY proceeds.
## Skill Invocation Checklist
- [ ] `sonar-scanner` uruchomiony po APPLY
- [ ] /frontend-design (opcjonalnie)
- [ ] /code-review (opcjonalnie)
</skills>
<acceptance_criteria>
## AC-1: Zakladka automatyzacji ma dwa taby z rozdzielonym zakresem
```gherkin
Given uzytkownik otwiera `/settings/automation`
When laduje sie ekran
Then widzi tab `Ustawienia` z obecna lista regul i akcjami CRUD
And widzi tab `Historia` z lista wykonan automatyzacji
```
## AC-2: Historia pokazuje co, kiedy i dla jakiego zamowienia
```gherkin
Given regula automatyzacji zostala wywolana przez trigger
When wykonanie reguly zakonczy sie sukcesem lub bledem
Then system zapisuje wpis historii zawierajacy co najmniej: event_type, rule_id/rule_name, order_id, status wykonania i timestamp
And wpis jest widoczny w tabie `Historia`
```
## AC-3: Historia wspiera filtrowanie i paginacje
```gherkin
Given tab `Historia` zawiera wpisy z wielu regul i zdarzen
When uzytkownik uzyje filtrow (np. event, status, rule, order_id, zakres dat) i zmieni strone
Then widok pokazuje tylko pasujace rekordy
And paginacja zachowuje aktywne filtry
```
## AC-4: Wpisy starsze niz 30 dni sa usuwane automatycznie
```gherkin
Given historia zawiera wpisy starsze niz 30 dni
When uruchomi sie harmonogram czyszczenia
Then wpisy starsze niz 30 dni zostana usuniete
And nowsze wpisy pozostaja bez zmian
```
## AC-5: Dokumentacja odzwierciedla nowy kontrakt historii automatyzacji
```gherkin
Given wdrozono nowa tabele i flow zapisu historii automatyzacji
When zespol czyta dokumentacje techniczna
Then `DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md` i `DOCS/TECH_CHANGELOG.md` opisuja nowe elementy
```
## AC-6: Automatyzacja obsluguje akcje zmiany statusu zamowienia
```gherkin
Given uzytkownik tworzy lub edytuje regule na `/settings/automation/create`
When wybierze akcje `Zmien status zamowienia` i wskaze status docelowy
Then konfiguracja zapisuje sie poprawnie
And po triggerze reguly status zamowienia jest zmieniany na wskazany status
And aktualizacja statusu jest zapisana zgodnie z obecnym flow historii statusow/activity log
```
</acceptance_criteria>
<tasks>
<task type="auto">
<name>Task 1: Dodaj model danych historii wykonania automatyzacji i retencje 30 dni</name>
<files>database/migrations/20260328_000072_create_automation_execution_logs_table.sql, src/Modules/Automation/AutomationExecutionLogRepository.php, src/Modules/Cron/AutomationHistoryCleanupHandler.php, src/Modules/Cron/CronHandlerFactory.php</files>
<action>
Dodaj migracje tworzaca tabele historii wykonan automatyzacji (`automation_execution_logs`) z indeksami pod filtry i sortowanie po czasie.
Dodaj repozytorium historii z metodami: insert wpisu wykonania, paginowane pobieranie z filtrami, count, purgeOlderThanDays(30).
Dodaj handler crona do cyklicznego usuwania starych wpisow i podlacz go w `CronHandlerFactory`.
Dodaj seed harmonogramu cleanup (`automation_history_cleanup`) tak, aby dzialal automatycznie bez recznej konfiguracji.
Trzymaj sie medoo/prepared statements i bez laczenia SQL stringiem przez wartosci dynamiczne.
</action>
<verify>rg -n "automation_execution_logs|automation_history_cleanup|purgeOlderThanDays|AutomationHistoryCleanupHandler" database/migrations src/Modules/Automation src/Modules/Cron</verify>
<done>AC-2 satisfied i AC-4 satisfied: dane historii sa zapisywane i maja automatyczna retencje 30 dni.</done>
</task>
<task type="auto">
<name>Task 2: Rozszerz AutomationService i kontroler o zapis historii oraz endpoint listowania</name>
<files>src/Modules/Automation/AutomationService.php, src/Modules/Automation/AutomationController.php, src/Modules/Automation/AutomationRepository.php, routes/web.php</files>
<action>
W `AutomationService::trigger` dodaj rejestracje wykonania per regula (co najmniej: event_type, rule_id, rule_name, order_id, result_status, result_message, executed_at), z logowaniem sukcesu i bledow bez zatrzymywania kolejnych regul.
Rozszerz `AutomationController::index` o obsluge query filtrow i paginacji historii oraz przekazanie danych do widoku.
Dodaj potrzebne metody repository do listowania filtrow pomocniczych (np. aktywne reguly/eventy) jesli sa potrzebne do UI.
Zadbaj, aby filtry/paginacja historii nie ingerowaly w istniejaca liste regul i zachowaly kompatybilnosc obecnych akcji CRUD.
</action>
<verify>rg -n "execution log|history|history_page|history_filters|logExecution|automation history" src/Modules/Automation routes/web.php</verify>
<done>AC-2 satisfied i AC-3 satisfied: backend dostarcza pelna historie z filtrowaniem i paginacja.</done>
</task>
<task type="auto">
<name>Task 3: Dodaj akcje `update_order_status` do automatyzacji (backend + formularz)</name>
<files>src/Modules/Automation/AutomationController.php, src/Modules/Automation/AutomationService.php, resources/views/automation/form.php, public/assets/js/modules/automation-form.js</files>
<action>
Rozszerz `ALLOWED_ACTION_TYPES` o nowa akcje `update_order_status` oraz walidacje konfiguracji tej akcji.
W `AutomationService` dodaj wykonanie akcji aktualizacji statusu zamowienia przez istniejacy, centralny flow domenowy (z zachowaniem wpisu historii statusow i activity log).
W formularzu automatyzacji dodaj nowa opcje akcji `Zmien status zamowienia` oraz selector statusu docelowego oparty o aktywne statusy orderPRO.
Utrzymaj zgodnosc create/edit i dynamicznego JS dodajacego kolejne akcje.
</action>
<verify>rg -n "update_order_status|Zmien status zamowienia|order_status|action_type" src/Modules/Automation resources/views/automation public/assets/js/modules/automation-form.js</verify>
<done>AC-6 satisfied: nowa akcja jest konfigurowalna i zmienia status zamowienia.</done>
</task>
<task type="auto">
<name>Task 4: Zbuduj UI dwoch tabow (Ustawienia/Historia) i zaktualizuj dokumentacje</name>
<files>resources/views/automation/index.php, resources/scss/modules/_automation.scss, public/assets/css/app.css, DOCS/DB_SCHEMA.md, DOCS/ARCHITECTURE.md, DOCS/TECH_CHANGELOG.md</files>
<action>
Przebuduj widok `/settings/automation` na taby zgodne ze stylem projektu (`content-tabs-nav` / `content-tab-panel`):
- tab `Ustawienia`: zachowuje obecna liste regul i akcje,
- tab `Historia`: tabela historii + formularz filtrow + paginacja.
Zachowaj kompaktowy layout (male odstepy, duza gestosc informacji) i brak natywnych `alert()/confirm()`.
Dodaj/uzupelnij style SCSS tylko w plikach SCSS, a nastepnie przebuduj CSS.
Zaktualizuj dokumentacje techniczna o nowa tabele historii oraz nowa akcje `update_order_status`.
</action>
<verify>rg -n "content-tabs-nav|Historia|Ustawienia|automation history|30 dni|automation_execution_logs|update_order_status" resources/views/automation/index.php resources/scss/modules/_automation.scss DOCS/DB_SCHEMA.md DOCS/ARCHITECTURE.md DOCS/TECH_CHANGELOG.md</verify>
<done>AC-1 satisfied i AC-5 satisfied: UI i dokumentacja sa zgodne z nowa funkcjonalnoscia.</done>
</task>
<task type="checkpoint:human-verify" gate="blocking">
<what-built>Tab `Historia` na `/settings/automation` z filtrowaniem i paginacja, automatyczna retencja wpisow 30 dni oraz akcja `Zmien status zamowienia`.</what-built>
<how-to-verify>
1. Otworz: `https://orderpro.projectpro.pl/settings/automation`.
2. Potwierdz obecnosc tabow: `Ustawienia` i `Historia`.
3. W tabie `Historia` ustaw filtry (event, status, order ID lub zakres dat) i sprawdz czy lista oraz licznik/paginacja sa zgodne.
4. Wywolaj testowo regule automatyzacji i potwierdz pojawienie sie nowego wpisu (co, kiedy, jakie zamowienie).
5. W `Ustawienia > Zadania automatyczne > Dodaj zadanie` wybierz akcje `Zmien status zamowienia`, ustaw status docelowy i zapisz regule.
6. Wyzwol regule i potwierdz realna zmiane statusu zamowienia na wybrany status.
7. Potwierdz dzialanie cleanupu wpisow >30 dni (przez uruchomienie joba cron lub test na danych historycznych).
</how-to-verify>
<resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
</task>
</tasks>
<boundaries>
## DO NOT CHANGE
- Logika tworzenia/edycji reguly automatyzacji poza koniecznymi zmianami pod nowe taby.
- Istniejace flow wysylki e-mail/paragonow/statusow przesylki poza dodaniem logowania wykonan.
- Istniejace flow zmiany statusu zamowienia poza rozszerzeniem go jako nowej akcji automatyzacji.
- Konfiguracja runtime DB host (`DB_HOST` pozostaje runtime; bez podpinania `DB_HOST_REMOTE`).
## SCOPE LIMITS
- Zakres dotyczy tylko ekranu `/settings/automation` i warstwy historii automatyzacji.
- Zakres obejmuje dodanie jednej nowej akcji automatyzacji: `update_order_status`.
- Bez zmian w innych ekranach ustawien.
- Bez dodatkowych funkcji biznesowych automatyzacji niezwi¹zanych z historia.
</boundaries>
<verification>
Before declaring plan complete:
- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationController.php`
- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationRepository.php`
- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationExecutionLogRepository.php`
- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationService.php`
- [ ] `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php`
- [ ] `C:\xampp\php\php.exe -l src/Modules/Cron/AutomationHistoryCleanupHandler.php`
- [ ] `C:\xampp\php\php.exe -l resources/views/automation/form.php`
- [ ] `C:\xampp\php\php.exe -l resources/views/automation/index.php`
- [ ] Migracja wykonuje sie poprawnie i tworzy indeksy historii
- [ ] Test paginacji/filtrow historii przechodzi
- [ ] Test akcji `update_order_status` przechodzi (zapis + wykonanie + zmiana statusu)
- [ ] Test cleanupu wpisow >30 dni przechodzi
- [ ] Dokumentacja zaktualizowana (`DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md`)
- [ ] All acceptance criteria met
</verification>
<success_criteria>
- `/settings/automation` ma dwa taby: `Ustawienia` i `Historia`.
- Historia pokazuje wykonania regul (co, kiedy, order) i ma filtry + paginacje.
- Akcja `Zmien status zamowienia` jest dostepna i poprawnie zmienia status na wybrany przez uzytkownika.
- Wpisy starsze niz 30 dni sa usuwane automatycznie.
- Dokumentacja techniczna odzwierciedla nowy model i przeplyw.
</success_criteria>
<output>
After completion, create `.paul/phases/49-automation-history-tab/49-01-SUMMARY.md`
</output>

147
.paul/phases/49-automation-history-tab/49-01-SUMMARY.md Normal file
View File

@@ -0,0 +1,147 @@
---
phase: 49-automation-history-tab
plan: 01
subsystem: automation
tags: [automation, history, cron, tabs, update_order_status]
requires:
- phase: 47-shipment-created-automation
provides: automation trigger shipment.created i akcje automatyzacji
provides:
- historia wykonan automatyzacji z filtrami i paginacja
- retencja historii 30 dni przez cron cleanup
- akcja automatyzacji update_order_status
affects: [settings-automation, cron, automation-service]
tech-stack:
added: []
patterns: [execution-log-per-rule, tabbed-settings-view, safe-automation-action-validation]
key-files:
created:
- database/migrations/20260328_000072_create_automation_execution_logs_table.sql
- src/Modules/Automation/AutomationExecutionLogRepository.php
- src/Modules/Cron/AutomationHistoryCleanupHandler.php
modified:
- src/Modules/Automation/AutomationController.php
- src/Modules/Automation/AutomationRepository.php
- src/Modules/Automation/AutomationService.php
- resources/views/automation/index.php
- resources/views/automation/form.php
- public/assets/js/modules/automation-form.js
key-decisions:
- "Historia automatyzacji zapisywana per regula (success/failed) bez blokowania glownego flow"
- "Nowa akcja update_order_status korzysta z centralnego OrdersRepository::updateOrderStatus"
- "Retencja historii realizowana cronem automation_history_cleanup (30 dni)"
patterns-established:
- "Tab settings/history z zapamietywaniem aktywnej zakladki"
- "Walidacja configu akcji automatyzacji po stronie kontrolera"
duration: ~55min
started: 2026-03-28T13:50:03+01:00
completed: 2026-03-28T14:45:16+01:00
---
# Phase 49 Plan 01: Automation History + Update Order Status Summary
**Dostarczono rozdzielenie `/settings/automation` na `Ustawienia/Historia`, audyt historii wykonan regul i akcje `update_order_status`, a dodatkowo po testach wdrozono hotfix fallbacku daty pickup dla Apaczka.**
## Performance
| Metric | Value |
|--------|-------|
| Duration | ~55 min |
| Started | 2026-03-28T13:50:03+01:00 |
| Completed | 2026-03-28T14:45:16+01:00 |
| Tasks | 4 completed |
| Files modified | 16+ |
## Acceptance Criteria Results
| Criterion | Status | Notes |
|-----------|--------|-------|
| AC-1: Dwa taby na `/settings/automation` | Pass | `resources/views/automation/index.php` ma taby `Ustawienia` i `Historia` |
| AC-2: Log co/kiedy/jakie zamowienie | Pass | `AutomationService::logExecution()` + `automation_execution_logs` |
| AC-3: Filtry + paginacja historii | Pass | `AutomationController::index` + `AutomationExecutionLogRepository::paginate/count` |
| AC-4: Auto-usuwanie wpisow >30 dni | Pass | cron `automation_history_cleanup` + `purgeOlderThanDays()` |
| AC-5: Dokumentacja techniczna | Pass | zaktualizowane `DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md` |
| AC-6: Akcja `update_order_status` | Pass | formularz + walidacja + wykonanie przez `OrdersRepository::updateOrderStatus` |
## Verification Results
- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationController.php` -> OK
- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationRepository.php` -> OK
- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationExecutionLogRepository.php` -> OK
- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationService.php` -> OK
- `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php` -> OK
- `C:\xampp\php\php.exe -l src/Modules/Cron/AutomationHistoryCleanupHandler.php` -> OK
- `C:\xampp\php\php.exe -l resources/views/automation/form.php` -> OK
- `C:\xampp\php\php.exe -l resources/views/automation/index.php` -> OK
- `sonar-scanner` uruchomiony pomyslnie (project `orderPRO`, dashboard updated)
## Files Created/Modified
| File | Change | Purpose |
|------|--------|---------|
| `database/migrations/20260328_000072_create_automation_execution_logs_table.sql` | Created | tabela historii + seed cleanup cron |
| `src/Modules/Automation/AutomationExecutionLogRepository.php` | Created | zapis/listowanie/paginacja/purge historii |
| `src/Modules/Cron/AutomationHistoryCleanupHandler.php` | Created | czyszczenie wpisow >30 dni |
| `src/Modules/Cron/CronHandlerFactory.php` | Modified | podpiety handler cleanup |
| `src/Modules/Automation/AutomationController.php` | Modified | backend tabu historii + nowa akcja update_order_status |
| `src/Modules/Automation/AutomationRepository.php` | Modified | sortowanie nazw regul + statusy zamowien do akcji |
| `src/Modules/Automation/AutomationService.php` | Modified | log execution + wykonanie update_order_status |
| `resources/views/automation/index.php` | Modified | taby, filtry i paginacja historii |
| `resources/views/automation/form.php` | Modified | UI akcji `Zmiana statusu zamowienia` |
| `public/assets/js/modules/automation-form.js` | Modified | dynamiczna obsluga nowej akcji |
| `DOCS/DB_SCHEMA.md` | Modified | kontrakt tabeli historii i zmiany flow |
| `DOCS/ARCHITECTURE.md` | Modified | opis nowego flow i akcji |
| `DOCS/TECH_CHANGELOG.md` | Modified | chronologia wdrozenia |
## Decisions Made
| Decision | Rationale | Impact |
|----------|-----------|--------|
| Log historii per regula (success/failed) | pelny audyt bez przerywania triggera | szybsza diagnostyka automatyzacji |
| `update_order_status` przez `OrdersRepository::updateOrderStatus` | reuse centralnego flow status history + activity log | brak duplikacji logiki i spojnosc domenowa |
| Cleanup historii jako cron | retencja bez manualnej obslugi | stabilny rozmiar danych |
## Deviations from Plan
### Summary
| Type | Count | Impact |
|------|-------|--------|
| Auto-fixed | 0 | None |
| Scope additions | 1 | Niski, uzasadniony produkcyjnym bledem |
| Deferred | 0 | None |
### Scope addition
- Po APPLY i testach produkcyjnych dodano hotfix `ApaczkaShipmentService`:
- fallback retry dla bledow niedostepnego dnia pickup (`Pickup not available...` oraz `you can't place an order today`),
- automatyczne przesuwanie `pickup.date` na kolejny dzien roboczy (max 7 prob).
- Powod: rzeczywisty blad operacyjny blokujacy tworzenie przesylek.
## Skill Audit
- Required `sonar-scanner`: invoked ✓
- Optional `/code-review`: not invoked
- Optional `/frontend-design`: not invoked
## Next Phase Readiness
**Ready:**
- Automatyzacja ma audytowalna historie z retencja.
- Reguly obsluguja automatyczna zmiane statusu zamowienia.
**Concerns:**
- Warto rozwazyc logowanie rowniez przypadkow `skipped` (warunki niespelnione), aby ulatwic debug bez diagnostyki DB.
**Blockers:**
- None
---
*Phase: 49-automation-history-tab, Plan: 01*
*Completed: 2026-03-28*