feat(01-purchase-data-layer): add post-payment purchase data layer
Phase 1 complete: - move purchase event to order confirmation after successful payment - add backend purchase payload builder for transaction and ticket lines - remove premature purchase push from przelewy24 redirect view
This commit is contained in:
148
.paul/phases/01-purchase-data-layer/01-01-PLAN.md
Normal file
148
.paul/phases/01-purchase-data-layer/01-01-PLAN.md
Normal file
@@ -0,0 +1,148 @@
|
||||
---
|
||||
phase: 01-purchase-data-layer
|
||||
plan: 01
|
||||
type: execute
|
||||
wave: 1
|
||||
depends_on: []
|
||||
files_modified:
|
||||
- autoload/controls/class.Tickets.php
|
||||
- templates/tickets/order-confirm.php
|
||||
- templates/tickets/przelewy24.php
|
||||
autonomous: true
|
||||
delegation: auto
|
||||
---
|
||||
|
||||
<objective>
|
||||
## Goal
|
||||
Wdroc event `purchase` do `dataLayer` dopiero po skutecznie oplaconym zamowieniu oraz przekazac maksymalnie kompletne dane transakcji i pozycji biletowych.
|
||||
|
||||
## Purpose
|
||||
Klient potrzebuje wiarygodnego trackingu ecommerce, w ktorym event zakupu nie odpala sie przed potwierdzeniem platnosci i zawiera dane gotowe do analityki GA4/GTM.
|
||||
|
||||
## Output
|
||||
- Logika backend przygotowujaca payload `purchase` z zamowienia
|
||||
- Przekazanie payloadu do widoku potwierdzenia zamowienia
|
||||
- Emisja `dataLayer.push` tylko dla zakonczonej platnosci
|
||||
- Usuniecie przedwczesnego eventu z widoku przekierowania do Przelewy24
|
||||
</objective>
|
||||
|
||||
<context>
|
||||
## Project Context
|
||||
@.paul/PROJECT.md
|
||||
@.paul/ROADMAP.md
|
||||
@.paul/STATE.md
|
||||
|
||||
## Source Files
|
||||
@autoload/controls/class.Tickets.php
|
||||
@autoload/factory/class.Tickets.php
|
||||
@templates/tickets/order-confirm.php
|
||||
@templates/tickets/przelewy24.php
|
||||
</context>
|
||||
|
||||
<acceptance_criteria>
|
||||
|
||||
## AC-1: Event tylko po potwierdzeniu platnosci
|
||||
```gherkin
|
||||
Given uzytkownik finalizuje zakup i wraca na strone potwierdzenia
|
||||
When zamowienie ma payment_status = 1
|
||||
Then event "purchase" jest pushowany do dataLayer na stronie order_confirm
|
||||
```
|
||||
|
||||
## AC-2: Pelny payload ecommerce
|
||||
```gherkin
|
||||
Given event "purchase" jest emitowany
|
||||
When skrypt buduje dane ecommerce
|
||||
Then payload zawiera transaction_id, value, currency, payment_date oraz items z product_id, name, quantity, price i date_visit
|
||||
```
|
||||
|
||||
## AC-3: Brak falszywych eventow
|
||||
```gherkin
|
||||
Given uzytkownik jest przekierowany do bramki platnosci
|
||||
When strona przelewy24 jest renderowana przed zakonczeniem platnosci
|
||||
Then event "purchase" nie jest emitowany na tym etapie
|
||||
```
|
||||
|
||||
</acceptance_criteria>
|
||||
|
||||
<tasks>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 1: Przygotuj backendowy builder payloadu purchase</name>
|
||||
<files>autoload/controls/class.Tickets.php</files>
|
||||
<action>
|
||||
Dodaj wydzielona metode budujaca tablice danych dla data layer na podstawie danych zamowienia:
|
||||
- Ustal stale pola ecommerce (transaction_id, value, currency, shipping)
|
||||
- Dodaj pola transakcyjne dostepne w systemie (payment_date, order_id, vat, city, zip_code)
|
||||
- Zmapuj pozycje `order_tickets` do `items` (item_id/product_id, item_name/name, quantity, price, date_visit)
|
||||
- Zapewnij poprawne typy liczbowe (float/int) i bezpieczne wartosci domyslne
|
||||
Unikaj: mieszania logiki mapowania danych bezposrednio w widoku.
|
||||
</action>
|
||||
<verify>php -l autoload/controls/class.Tickets.php</verify>
|
||||
<done>AC-2 satisfied: payload ecommerce zawiera pelny i spojny zestaw danych</done>
|
||||
</task>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 2: Przepnij emisje purchase na order_confirm po oplaceniu</name>
|
||||
<files>autoload/controls/class.Tickets.php, templates/tickets/order-confirm.php</files>
|
||||
<action>
|
||||
W kontrolerze `order_confirm` przekaz do widoku gotowy payload purchase tylko gdy zamowienie jest skutecznie oplacone.
|
||||
W widoku `order-confirm.php` dodaj warunkowy skrypt:
|
||||
- reset ecommerce (`dataLayer.push({ ecommerce: null })`)
|
||||
- push eventu `purchase` z payloadem z backendu
|
||||
- serializacja przez `json_encode(..., JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS|JSON_HEX_QUOT)` dla bezpieczenstwa XSS
|
||||
- defensywna obsluga przypadku braku `window.dataLayer`
|
||||
Unikaj: recznego skladania JSON przez konkatenacje stringow.
|
||||
</action>
|
||||
<verify>php -l autoload/controls/class.Tickets.php && php -l templates/tickets/order-confirm.php</verify>
|
||||
<done>AC-1 satisfied: purchase emituje sie po potwierdzonej platnosci na stronie potwierdzenia</done>
|
||||
</task>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 3: Usun przedwczesny purchase z widoku przelewy24 i sprawdz brak regresji</name>
|
||||
<files>templates/tickets/przelewy24.php</files>
|
||||
<action>
|
||||
Usun blok `dataLayer.push` z eventem `purchase` z `przelewy24.php`, pozostawiajac tylko auto-submit formularza do bramki platnosci.
|
||||
Zweryfikuj recznie scenariusz:
|
||||
- Wejscie na strone Przelewy24 nie emituje `purchase`
|
||||
- Powrot na `order_confirm` po statusie payment_status=1 emituje `purchase` z danymi
|
||||
Unikaj: modyfikacji logiki podpisu i parametrow requestu do Przelewy24.
|
||||
</action>
|
||||
<verify>php -l templates/tickets/przelewy24.php</verify>
|
||||
<done>AC-3 satisfied: purchase nie odpala sie przed potwierdzeniem platnosci</done>
|
||||
</task>
|
||||
|
||||
</tasks>
|
||||
|
||||
<boundaries>
|
||||
|
||||
## DO NOT CHANGE
|
||||
- Logika weryfikacji podpisu i statusu w `przelewy24_response()`
|
||||
- Integracja fakturowania w `class.Tickets.php` (sekcja fakturowo API)
|
||||
- Inne moduly niezwiązane z checkoutem biletowym
|
||||
|
||||
## SCOPE LIMITS
|
||||
- Bez zmian schematu bazy danych
|
||||
- Bez przebudowy calego widoku `order-confirm.php` poza sekcja data layer
|
||||
- Bez zmian flow koszyka i formularza zamowienia poza danymi eventu purchase
|
||||
|
||||
</boundaries>
|
||||
|
||||
<verification>
|
||||
Before declaring plan complete:
|
||||
- [ ] `php -l autoload/controls/class.Tickets.php`
|
||||
- [ ] `php -l templates/tickets/order-confirm.php`
|
||||
- [ ] `php -l templates/tickets/przelewy24.php`
|
||||
- [ ] Reczny test checkout: brak purchase na `przelewy24`, obecny purchase na `order_confirm` po platnosci
|
||||
- [ ] Wszystkie acceptance criteria spelnione
|
||||
</verification>
|
||||
|
||||
<success_criteria>
|
||||
- Wszystkie taski wykonane bez regresji flow zakupowego
|
||||
- Event `purchase` wysylany tylko po skutecznej platnosci
|
||||
- Payload zawiera komplet dostepnych danych transakcyjnych i pozycje biletowe
|
||||
- Kod pozostaje zgodny z zasadami czytelnosci i bezpieczenstwa widokow
|
||||
</success_criteria>
|
||||
|
||||
<output>
|
||||
After completion, create `.paul/phases/01-purchase-data-layer/01-01-SUMMARY.md`
|
||||
</output>
|
||||
Reference in New Issue
Block a user