# Codebase Concerns

**Analysis Date:** 2026-03-12

---

## Tech Debt


### [MEDIUM] SonarQube — 327 Open Issues (2026-03-12)

Listed in `DOCS/todo.md`:
- 95x `php:S112` — generic `new \Exception` instead of typed exceptions
- 57x `php:S1142` — excessive `return` statements per method
- 40x `php:S1192` — repeated string literals not extracted to constants
- 31x `php:S3776` — high cognitive complexity
- 11x `php:S1448` — classes with too many methods (god classes)
- 4x `php:S138` — methods over the allowed line limit

The most critical from a maintainability standpoint are the complexity and god-class violations.

---

### [LOW] Duplicate Migration Number `000014`

- Issue: Two migration files share sequence number `000014`:
  - `20260227_000014_create_product_integration_translations.sql`
  - `20260301_000014_add_products_sku_format_setting.sql`
- File: `database/migrations/`
- Impact: Depending on how the migrator detects "already run" (by filename vs. sequence number), one of these may silently never execute or may fail.
- Fix approach: Rename one to `000014b` or renumber all subsequent ones. Verify migrator uses full filename as key.

---

## Security Concerns

### [HIGH] No SSL Verification on cURL Calls

- Issue: None of the `AllegroApiClient`, `ShopproApiClient`, `ApaczkaApiClient`, or `AllegroOAuthClient` set `CURLOPT_SSL_VERIFYPEER` or `CURLOPT_SSL_VERIFYHOST`. PHP's default is to verify SSL, but explicitly not setting it means behavior depends on the server's `php.ini` `curl.cainfo` configuration.
- Files:
  - `src/Modules/Settings/AllegroApiClient.php`
  - `src/Modules/Settings/AllegroOAuthClient.php`
  - `src/Modules/Settings/ShopproApiClient.php`
  - `src/Modules/Settings/ApaczkaApiClient.php`
- Impact: On environments without a properly configured CA bundle (common on shared hosting / Windows XAMPP), all API calls may proceed without SSL verification, enabling MITM attacks on OAuth tokens and API keys.
- Fix approach: Explicitly set `CURLOPT_SSL_VERIFYPEER => true` and configure `CURLOPT_CAINFO` pointing to a known CA bundle. Document this in `.env.example`.

---

### [MEDIUM] CSRF Token Is Never Rotated After Login

- Issue: `Csrf::token()` in `src/Core/Security/Csrf.php` generates the token once per session and never regenerates it. The token is never rotated after a successful login, and it is never invalidated after a POST form is submitted.
- File: `src/Core/Security/Csrf.php`
- Impact: If a CSRF token leaks (e.g., via Referer header, browser history), it remains valid for the entire session lifetime.
- Fix approach: Rotate the CSRF token on login. Optionally regenerate after each use (per-form tokens). At minimum, invalidate the session token on `AuthService::logout()`.

---

### [MEDIUM] Label File Served with `file_get_contents($fullPath)` — Partial Path Traversal Risk

- Issue: In `ShipmentController::label()`, the file path is built from `$package['label_path']` retrieved from the database. While `basename()` is used for the filename in the response header, `$fullPath` itself is derived by concatenating `$storagePath . '/labels/' . $filename` from the shipment service. There is no `realpath()` check confirming the file is actually within the storage directory before serving it.
- File: `src/Modules/Shipments/ShipmentController.php` (lines 292–316)
- Impact: Low risk currently (path comes from DB, not user input directly), but if `label_path` column is ever injectable or incorrectly set, arbitrary file reads become possible.
- Fix approach: Validate `realpath($fullPath)` starts with `realpath($storagePath)` before calling `file_get_contents()`.

---

### [LOW] Allegro OAuth Callback Endpoint Has No Auth Middleware

- Issue: `GET /settings/integrations/allegro/oauth/callback` is registered without `$authMiddleware`. The OAuth state parameter is validated via session, which does provide CSRF protection for the OAuth flow, but any authenticated check is absent.
- File: `routes/web.php` (line 239)
- Impact: An unauthenticated actor with knowledge of the state parameter could complete an OAuth token exchange. In practice, the state must match the session, limiting exploitability to session-fixation scenarios.
- Fix approach: Add `$authMiddleware` to the callback route. Handle the "not authenticated yet" edge case by storing the session state before redirect.

---

## Performance Concerns

### [HIGH] N+1 Correlated Subqueries on Every Order List Row

- Issue: The `OrdersRepository::paginate()` list SQL includes three correlated subqueries per row: `items_count`, `items_qty`, `shipments_count`, and `documents_count`. These fire once per order in the result set.
- File: `src/Modules/Orders/OrdersRepository.php` (lines 124–127)
- Impact: For a page of 50 orders: 4 × 50 = 200 additional subquery executions per page load. Degrades significantly as the `orders` table grows.
- Fix approach: Replace correlated subqueries with LEFT JOIN + GROUP BY aggregates, or preload counts in a single separate query (`SELECT order_id, COUNT(*) ... GROUP BY order_id WHERE order_id IN (...)`).

---

### [HIGH] `canResolveMappedMedia()` Queries `information_schema.COLUMNS` on Every Request

- Issue: `OrdersRepository::canResolveMappedMedia()` runs a query against `information_schema.COLUMNS` to check whether optional product mapping tables exist. It caches the result in a private property, but this property is instance-scoped — the check fires once per HTTP request that instantiates `OrdersRepository`.
- File: `src/Modules/Orders/OrdersRepository.php` (lines 604–648)
- Impact: `information_schema` queries are notoriously slow on MySQL. This fires on every order-related page load (list, detail, shipment).
- Fix approach: Cache the result in a static class property or in the app-level cache/session so it survives across requests. Alternatively, remove the check entirely — if the schema is managed by migrations, the tables either exist or don't.

---

### [MEDIUM] AllegroStatusSyncService Fetches Up to 50 Orders Then Re-Imports Each One Fully

- Issue: `AllegroStatusSyncService::findOrdersNeedingStatusSync()` returns up to 50 Allegro orders. For each, `importSingleOrder()` is called, which makes a full Allegro API call per order (checkout-form fetch + optional shipments fetch + optional offer image fetch per line item). This is 50+ API calls per cron run.
- File: `src/Modules/Settings/AllegroStatusSyncService.php`
- Impact: Rate-limit exhaustion on Allegro API. Slow cron runs.
- Fix approach: Use a lighter-weight API call to fetch only status fields for multiple orders (e.g., `listCheckoutForms` with a filter) rather than a full re-import per order.
- Note (2026-03-13): Plan 02-02 dodał kursor `last_status_checked_at` — eliminuje re-import zamówień bez zmiany statusu. Full API call per order pozostaje osobnym concernem.

---

### [MEDIUM] No Database Indexes Verified for Key Queries

- Issue: Queries frequently filter and sort on `orders.source`, `orders.external_status_id`, `orders.ordered_at`, `order_items.order_id`, and `allegro_order_status_mappings.allegro_status_code`. Whether indexes exist for these columns is not documented.
- Files: `src/Modules/Orders/OrdersRepository.php`, `database/migrations/20260302_000018_create_orders_tables_and_schedule.sql`
- Impact: Full table scans as data grows.
- Fix approach: Audit the migration that creates `orders` and related tables for index definitions. Add missing indexes for `(source, external_status_id)`, `(ordered_at)`, and `allegro_status_code`.

---

## Architectural Concerns

### [HIGH] `Settings` Module Is a God Module — Contains Unrelated Concerns

- Issue: The `src/Modules/Settings/` directory contains 30+ classes covering: Allegro integration, Apaczka integration, InPost integration, shopPRO integration, company settings, cron settings, order statuses, carrier mappings, delivery method mappings, and OAuth. These are logically distinct domains crammed into a single module namespace.
- Files: All files in `src/Modules/Settings/`
- Impact: The module boundary is meaningless. New integrations will continue to pile into Settings. `AllegroIntegrationController` (923 lines) and `ShopproIntegrationsController` (901 lines) are god classes by SonarQube rules (S1448).
- Fix approach: Gradually decompose into purpose-built modules: `src/Modules/Integrations/Allegro/`, `src/Modules/Integrations/Shoppro/`, `src/Modules/Integrations/Apaczka/`, `src/Modules/Integrations/Inpost/`.

---

### [HIGH] `AllegroIntegrationController` and `ShopproIntegrationsController` Are God Classes (900+ lines)

- Issue: Each controller handles: displaying settings, saving credentials, OAuth flow, status mapping CRUD, delivery method mapping CRUD, and import triggering. Each is 900+ lines.
- Files:
  - `src/Modules/Settings/AllegroIntegrationController.php` (923 lines)
  - `src/Modules/Settings/ShopproIntegrationsController.php` (901 lines)
- Impact: Violates SRP. Methods average far more than 50 lines. Cognitive complexity is high (SonarQube S3776, 31 violations).
- Fix approach: Split each into focused controllers per tab/concern: e.g., `AllegroCredentialsController`, `AllegroStatusMappingController`, `AllegroDeliveryMappingController`.

---

### [HIGH] `ShopproOrdersSyncService` Is 1192 Lines — Largest Single File

- Issue: `ShopproOrdersSyncService` handles the full import lifecycle for shopPRO orders including: pagination, cursor management, order mapping, address building, item building, image resolution, payment mapping, shipment mapping, status history, and activity logging — all in one class.
- File: `src/Modules/Settings/ShopproOrdersSyncService.php`
- Impact: Highest complexity class in the codebase. Hard to test, hard to modify, prone to regression.
- Fix approach: Extract a `ShopproOrderMapper` (mapping logic), a `ShopproImageResolver` (image fetch), and keep `ShopproOrdersSyncService` as the orchestrator. Mirror the pattern of `AllegroOrderImportService` which is better separated.

---

### [MEDIUM] No Dependency Injection Container — Full Object Graph in `routes/web.php`

- Issue: `routes/web.php` manually constructs all services and controllers, including multiple separate instantiations of identical objects (e.g., `new AllegroApiClient()` appears 3 times, `new OrdersRepository($app->db())` appears 4 times).
- File: `routes/web.php`
- Impact: Multiple object instances where singletons are implied. Adding new dependencies requires editing this file, which is already 257 lines. Risk of silently passing the wrong instance.
- Fix approach: Introduce a lightweight DI container or service locator. At minimum, hoist shared instances (`$allegroApiClient`, `$ordersRepository`) to named variables and reuse them.

---


## Incomplete Features

### [HIGH] 5 Stub Buttons with No Actions in Order Detail View

- Issue: The order detail page (`resources/views/orders/show.php`, lines 48–53) contains 5 buttons that render in the UI but have no `href`, no form action, and no JavaScript handler: "Strefa klienta", "Platnosc", "Drukuj", "Pakuj", "Edytuj".
- File: `resources/views/orders/show.php`
- Impact: Users see clickable but non-functional UI elements. The "Pakuj" (pack) button is styled as the primary CTA (`btn--primary`).
- Fix approach: Either implement the features or hide the buttons until they are ready.

---

### [HIGH] `orderpro_to_allegro` Status Sync Direction Not Implemented

- Issue: The setting UI offers two sync directions: Allegro → orderPRO and orderPRO → Allegro. The second direction explicitly returns early with "Kierunek orderPRO -> Allegro nie jest jeszcze wdrozony" ("not yet implemented").
- File: `src/Modules/Settings/AllegroStatusSyncService.php` (lines 38–45)
- Impact: Users who configure the "push status to Allegro" direction get silent no-op behavior with no clear user-facing indication in the cron log.
- Fix approach: Either implement the feature or disable the `orderpro_to_allegro` direction option in the UI until it is ready.

---

### [HIGH] TODO in `DOCS/todo.md` — UI Issues Open

The following items from `DOCS/todo.md` are marked incomplete:
- Item 12: Status change sync with Allegro after manual user change
- Item 14: Input/select/textarea border color needs to be darker
- Item 15: Source and ID display order should be reversed (source first, then ID)
- Item 16: Order list statuses should be colored according to settings
- Item 17: Source display should show specific integration name instead of "shopPRO"; ID label missing
- Files: `resources/views/orders/list.php`, `resources/views/orders/show.php`

---

### [MEDIUM] InPost Integration — Settings Page Exists But No Shipment Provider

- Issue: `InpostIntegrationController` and `InpostIntegrationRepository` exist and the settings page at `/settings/integrations/inpost` is functional. However, there is no `InpostShipmentService` implementing `ShipmentProviderInterface`. InPost labels are currently routed through `allegro_wza` as a workaround (`provider_code === 'inpost'` is remapped to `'allegro_wza'` in `ShipmentController::create()`).
- Files:
  - `src/Modules/Settings/InpostIntegrationController.php`
  - `src/Modules/Settings/InpostIntegrationRepository.php`
  - `src/Modules/Shipments/ShipmentController.php` (line 165–166)
- Impact: InPost credentials are stored but not used by their own provider. The remap to `allegro_wza` means InPost shipments are actually created via Allegro WZA. This breaks if the user has only InPost credentials and no Allegro integration.
- Fix approach: Implement `InpostShipmentService implements ShipmentProviderInterface` using the stored InPost API token.

---

### [MEDIUM] `database/drafts/` Contains Uncommitted Schema SQL

- Issue: `database/drafts/20260302_orders_schema_v1.sql` exists in the `drafts` subdirectory. This is not a migration — it will not be executed by the migrator.
- File: `database/drafts/20260302_orders_schema_v1.sql`
- Impact: Unclear whether this represents schema that has not yet been migrated or schema that was migrated by other means. Creates confusion about source of truth.
- Fix approach: Either move to `database/migrations/` with a proper sequence number, or delete it if already superseded.

---

## Known Bugs


## Test Coverage Gaps

### [HIGH] No Integration or Functional Tests Exist

- Issue: The `tests/` directory contains only `bootstrap.php`. No test files exist. The `archive/` directory contains unit tests from a previous reset, but they are not in active use.
- Files: `tests/bootstrap.php`, `archive/2026-03-02_users-only-reset/tests/`
- Risk: Zero automated coverage for any critical path: order import, shipment creation, OAuth flow, cron sync, status updates.
- Priority: High

---

### [HIGH] Allegro OAuth Token Refresh Logic Has No Tests

- Issue: The token refresh logic is centralized in `AllegroTokenManager` but untested. It includes complex edge cases: token expiry within 5-minute window, empty refresh token fallback, write-then-re-read pattern.
- Files: `src/Modules/Settings/AllegroTokenManager.php`
- Risk: Token refresh failures cause complete import failure. Silent breakage possible.
- Priority: High

---

### [MEDIUM] No Error Path Tests for Order Import

- Issue: `AllegroOrderImportService::importSingleOrder()` and `ShopproOrdersSyncService::sync()` have complex error handling (401 retry, silent Throwable catch blocks). None of this is tested.
- Files:
  - `src/Modules/Settings/AllegroOrderImportService.php`
  - `src/Modules/Settings/ShopproOrdersSyncService.php`
- Risk: Error paths that swallow exceptions silently (multiple `catch (Throwable) {}` blocks in `OrdersRepository`) may hide data integrity issues.
- Priority: Medium

---

## Fragile Areas

### [HIGH] `AllegroStatusSyncService` — `orderpro_to_allegro` Silent No-Op

- Files: `src/Modules/Settings/AllegroStatusSyncService.php`
- Why fragile: Returns `ok: true` when direction is `orderpro_to_allegro` with zero processing, no log, no user feedback. Cron logs will show "success" even though nothing happened.
- Safe modification: Do not add code after the early return without understanding why it was left as a no-op. Consider returning `ok: false` or a warning until the feature is implemented.
- Test coverage: None.

---

### [MEDIUM] Web Cron Throttling Uses Session Timestamp (`$_SESSION['cron_web_last_run_at']`)

- Issue: `Application::isWebCronThrottled()` reads and writes a cron timestamp from `$_SESSION`. In stateless or load-balanced deployments, different users hit different sessions, meaning the throttle is per-session (per-user), not global.
- File: `src/Core/Application.php` (lines 363–375)
- Why fragile: With two active sessions, the cron may run twice within the throttle window. The DB-level `GET_LOCK` is the real protection, but this creates confusing interactions.
- Fix approach: Move last-run timestamp to the database (e.g., an `app_settings` key) instead of the session.

---

*Concerns audit: 2026-03-12*
