CRUD notatek autorskich operatora per zamowienie z badge [N] na liscie
zamowien. Reuse istniejacej tabeli `order_notes` przez nowy
`note_type='user'` z `user_id` (FK->users SET NULL) i `author_name`
(snapshot). Sekcja `#notes` w "Wiadomosci i zalaczniki" w
`/orders/{id}` z inline edit form + delete przez
`OrderProAlerts.confirm`. Autoryzacja DB-level
(`WHERE user_id = :user_id`, rowCount=0 ⇒ 403) — bez admin override
(brak systemu rol w aplikacji).
- Migracja `20260514_000116_*.sql` (ADD COLUMN user_id + author_name +
FK + indeks `idx_order_notes_type_order`); idempotentne z DDL
no-op fallback.
- `OrderNotesService` (CRUD + walidacja body ≤ 2000 znakow); subquery
`user_notes_count` w paginate; badge HTML w `toTableRow()`.
- 3 routy POST /orders/{id}/notes(/update|/delete).
- SCSS module `_order-notes.scss` + vanilla JS `order-notes.js`
(inline edit toggle + delete confirm; idempotent guard).
- 9 kluczy i18n PL; PROJECT.md + ROADMAP.md + tech_changelog.md +
db_schema.md zaktualizowane.
Follow-up: `php bin/migrate.php` + manualny smoke test (autor vs inny
user + badge na /orders/list).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PolkurierApiClient rozszerzony do pelnego kontraktu (7 metod):
createShipment/getLabel/getStatus/cancelOrder/getAvailableCarriers/
getInpostParcelMachines/getCourierPoints. Wspolny call() parsuje
envelope {status, response}. Kontrakt zweryfikowany na oficjalnej
dokumentacji PDF v1.11.
PolkurierShipmentService (implements ShipmentProviderInterface)
orchestruje pelen flow: normalizeShipmentType (lowercase), split
ulicy, build recipient/sender/pickup, COD z bank account z
company_settings, extractOrderNumber/extractTrackingNumber
priorytetujace SDK Order entity (number, waybills[0].number).
PolkurierTrackingService (implements ShipmentTrackingInterface)
mapuje statusy O/P/A/WP/D/Z/W przez delivery_status_mappings.
UI panel polkurier w prepare.php z dynamiczna lista uslug z
available_carriers. Bez dedykowanego selektora punktu — operator
wpisuje receiver_point_id w istniejace pole w sekcji Adres odbiorcy.
Migracja 20260514_000115 seedujaca 7 wpisow delivery_status_mappings
z oficjalnej tabeli ORDER_STATUS (O/P/A/WP/D/Z/W).
Live test #114/#115 zakonczony sukcesem po 4 iteracjach
(ReferenceError -> uppercase shipmenttype -> orderno parsing ->
A4/A6 etykieta). Rozmiar etykiety A4/A6 sterowany w panelu klienta
polkurier.pl, NIE przez API.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Single-instance globalna konfiguracja polkurier.pl jako alternatywa
dla Apaczki: szyfrowany login + Token API, karta w hubie integracji
i realny test polaczenia przez apimetod=test_auth_api zweryfikowany
na zywym koncie operatora (Autoryzacja: 1).
ShipmentProviderRegistry netkniety - PolkurierShipmentService/
TrackingService w kolejnych fazach.
Kluczowe ustalenia kontraktu API (z SDK polkurier-sdk):
- POST https://api.polkurier.pl/ (jeden endpoint)
- JSON body: {authorization:{login,token}, apimetod, data}
- Sukces: top-level status === 'success' (nie 'ok')
- Blad: tresc w polu 'response' envelope'a
- Content-Type: application/json (strict, bez charset suffix)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Nowa tabela sms_templates (name + body + is_active) + minimalny CRUD.
- /settings/sms-templates: lista + formularz z paleta zmiennych (pill chips).
- Wydzielono Sms\SmsVariableResolver ze wspolna logika placeholderow;
Email\VariableResolver staje sie cienka fasada — EmailSendingService bez zmian.
- Dropdown "Wybierz szablon" w zakladce SMS na /orders/{id} z fetch
GET /orders/{id}/sms/template + OrderProAlerts.confirm przy nadpisaniu.
- Stopka SMSPLANET dalej doklejana wylacznie przez SmsConversationService
(Phase 122 contract preserved).
- Sidebar Ustawien: nowy link "Szablony SMS".
Migration: 20260512_000112_create_sms_templates.sql (CREATE TABLE).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 116 complete:
- add HostedSMS settings with encrypted password storage
- add SimpleAPI real test SMS flow and integrations hub row
- document schema, architecture, changelog, and PAUL state
Co-Authored-By: Codex <noreply@openai.com>
Phase 110 complete:
- add Statistics -> Podsumowanie page
- add monthly order count and value charts per integration plus total
- use Chart.js with table fallback and 04-2026 default history start
- update PAUL and DOCS technical documentation
- Implemented buildUserAgent() method in AllegroApiClient, AllegroOAuthClient, and AllegroTrackingService to include User-Agent header in all HTTP requests to Allegro API.
- Updated .env.example to include APP_VERSION and ALLEGRO_USER_AGENT_URL for configuration.
- Created public /info page to provide application details required by Allegro, including app name, version, description, and contact information.
- Added minimalist layout for public pages to ensure a professional appearance.
- Ensured all changes comply with Allegro's API requirements for User-Agent header.
Phase 29 complete (v1.3):
- Tabela delivery_status_mappings z DB overrides
- DeliveryStatus: normalizeWithOverrides(), descriptionWithOverrides(), getDefaultMappings()
- UI ustawień: tabela mapowań per provider (InPost/Apaczka/Allegro), bulk save, reset, resetAll
- 5 endpointów w routes/web.php, link w menu bocznym
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nowy endpoint POST /orders/{id}/shipment/manual z formularzem inline
w zakladce Przesylki. Reuse tabeli shipment_packages (provider='manual',
status='created'). Activity log, walidacja CSRF, HTML required.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Reguły automatyzacji oparte na zdarzeniach (receipt.created) z warunkami
(integracja/kanał sprzedaży, AND logic) i akcjami (wyślij e-mail z 3 trybami
odbiorcy: klient / firma / klient+firma). Trigger w ReceiptController po
utworzeniu paragonu — błąd automatyzacji nie blokuje sukcesu paragonu.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
3 migrations (email_mailboxes, email_templates, email_logs), full CRUD
for SMTP mailboxes with encrypted passwords (IntegrationSecretCipher),
native SMTP connection test via stream_socket_client, sidebar navigation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 11: Receipt preview, print & PDF via dompdf.
Phase 12: Accounting section with receipt list, filters, pagination,
selectable checkboxes and XLSX export via PhpSpreadsheet.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add receipt show/print/pdf endpoints with dompdf integration.
Active preview and PDF links in order Documents tab.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Introduced ShipmentProviderInterface to define the contract for shipment providers.
- Implemented ShipmentProviderRegistry to manage and retrieve shipment providers.
- Added a new tool for probing Apaczka order_send payload variants, enhancing debugging capabilities.
- Implemented ShopproPaymentStatusSyncService to handle payment status synchronization between Shoppro and Orderpro.
- Added methods for resolving watched status codes, finding candidate orders, and syncing individual order payments.
- Introduced ShopproStatusMappingRepository for managing status mappings between Shoppro and Orderpro.
- Created ShopproStatusSyncService to facilitate synchronization of order statuses from Shoppro to Orderpro.
- Added a check for available InPost services and display a message if none are found.
- Updated the InPost service selection dropdown to include additional data attributes for better handling in JavaScript.
- Improved JavaScript event handling for InPost service selection to correctly populate hidden fields with selected service data.
feat: Introduce Cash on Delivery (COD) functionality in shipment preparation
- Added a new input field for specifying the COD amount and currency in the shipment preparation view.
- Updated the shipment creation logic to handle COD amounts correctly when creating shipments.
refactor: Update OrdersController to include shipment package repository
- Modified the OrdersController to accept a ShipmentPackageRepository for better management of shipment-related data.
- Enhanced order details to include shipment package information.
fix: Ensure internal order numbers are generated upon order creation
- Updated the OrderImportRepository to generate and store internal order numbers when a new order is created.
feat: Implement status synchronization for Allegro orders
- Introduced a new service for syncing order statuses from Allegro to the internal system.
- Added logic to fetch and process orders needing status updates, handling errors gracefully.
chore: Clean up InPost service definitions in AllegroIntegrationController
- Removed hardcoded InPost service definitions and replaced them with dynamic fetching based on available services.
feat: Add activity logging for shipment actions
- Implemented activity logging for various shipment actions, including creation, label downloads, and errors, to improve traceability and auditing.
- Implement AllegroShipmentService for managing shipment creation and status checks.
- Create ShipmentController to handle shipment preparation and label downloading.
- Introduce ShipmentPackageRepository for database interactions related to shipment packages.
- Add methods for retrieving delivery services, creating shipments, checking creation status, and downloading labels.
- Implement address validation and token management for Allegro API integration.
- Added AllegroOrderSyncStateRepository for managing sync state with Allegro orders.
- Introduced AllegroOrdersSyncService to handle the synchronization of orders from Allegro.
- Created AllegroStatusDiscoveryService to discover and store order statuses from Allegro.
- Developed AllegroStatusMappingRepository for managing status mappings between Allegro and OrderPro.
- Implemented AllegroStatusSyncService to facilitate status synchronization.
- Added CronSettingsController for managing cron job settings related to Allegro integration.
- Implemented OrdersRepository for handling order data with pagination, filtering, and sorting capabilities.
- Added methods for retrieving order status options, quick stats, and detailed order information.
- Created OrderStatusRepository for managing order status groups and statuses, including CRUD operations and sorting.
- Introduced a bootstrap file for test environment setup and autoloading.
