# Test Bugs & Change Tracker

Running log of backend API failures found during testing and the corresponding frontend changes needed. Add one entry per issue found; move to "Resolved" once fixed and verified.

## Open

| # | Area | Backend API Failure | Frontend Change Needed | Date |
|---|------|----------------------|--------------------------|------|
| 6 | Sales → Visits (Route dropdown) | Selecting a specific route in the route dropdown does not filter route sales — all routes still show; check-in also not working | Fix route filter and check-in on Sales Visits page. **Partial fix landed (#49)**: `GET /stores?routeId=...` now actually filters server-side, so the store list for a selected route should now be correct — check-in itself still needs investigating | 2026-09-02 |
| 7 | Catalogue → Categories (Subcategories) | Added subcategories don't display in the FE | Fix subcategory list rendering | Add a View icon to the action column in Categories table | 2026-09-02 |
| 8 | Stock Balances |  | Add a View icon to the action column in Stock Balances table; allow Edit | 2026-09-02 |
| 9 | Stock Movements | Some rows missing From/To locations — every movement should always have both | Add a View icon and an Edit icon to the action column in Stock Movements table | 2026-09-02 |
| 10 | Procurement → Orders (Place Order) | Placing a new order throws: `var userId = currentUser.UserId ?? throw new UnauthorizedAccessException();` | Add action icons to the action column in Procurement Orders table | 2026-09-02 |
| 11 | Procurement → GRN |  | Full module CRUD check pending (CRUD + action icons) | 2026-09-02 |
| 12 | Pricing |  | Full module CRUD check pending (frontend + CRUD + action icons) | 2026-09-02 |
| 13 | Pricing → Schemes (Add Scheme modal) |  | Add Scheme modal should show a rule-type-specific "value" input field that changes based on the selected Scheme Name/Rule Type (currently no dynamic value field for the chosen rule type) | 2026-09-02 |
| 14 | Suppliers |  | Add a View icon and a Cancel icon to the action column in Suppliers table | 2026-09-02 |
| 15 | Driver Profiles | Delete doesn't work | Add a View icon to the action column in Driver Profiles table | 2026-09-02 |
| 16 | Users | Delete action not working | Add View icon | 2026-09-02 |
| 17 | Users → Roles |  | For now, hide the Add Role icon and the Edit/Cancel (deactivate) icons in the action column; keep only the View icon | 2026-09-02 |
| 18 | Network → Regions | Adding a region that already exists is not blocked — no duplicate-name validation; deleting a region does not work (backend as well) | Add View action icon to the action column; when status is Inactive, region should actually be set to inactive and reflect that status in the frontend | 2026-09-02 |
| 19 | Network → Region Manage |  | Remove the Rule Config JSON-type field from the frontend view; add a View icon to the action column; on Cancel, just set status to Inactive and reflect that in the UI | 2026-09-02 |
| 20 | Network → Routes | Inactive status doesn't work properly | Check Manage Owner and Manage Stores actions; add View icon to the action column; check Cancel action too | 2026-09-02 |
| 21 | Network → Vehicles |  | Add a View icon to the action column; check Cancel action | 2026-09-02 |
| 22 | Network → Warehouses | Delete doesn't work | Add a View icon to the action column; check Inactive status | 2026-09-02 |
| 23 | Returns & Claims Management | `ReturnController`, `ClaimController`, `SupplierClaimController` all exist and are fully implemented | No frontend integration at all — no API client, no pages/UI for order returns, claims, or supplier claims. Build the module end-to-end | 2026-09-02 |
| 24 | Procurement → Purchase Returns | `PurchaseReturn` CRUD fully implemented | No frontend API client and no UI at all for purchase returns. Build the module end-to-end | 2026-09-02 |
| 25 | Orders (CRUD gap) | Create/Update/Delete endpoints exist and work | Orders page is read-only in the frontend — only list/get are wired up; add Create/Update/Delete UI | 2026-09-02 |
| 26 | Pricing → Schemes (unused capability) | Eligibility check, spend/ROI analytics, and apply-scheme-to-order endpoints all exist | None of these are wired into the frontend — only basic scheme CRUD is; add UI for eligibility check, spend/ROI view, and applying a scheme to an order | 2026-09-02 |
| 27 | Misc missing Delete actions | Delete/soft-delete endpoints exist for Users, Stores, Price Lists, and Suppliers | No Delete UI wired up for these on their respective pages | 2026-09-02 |
| 28 | Auth (root cause of #10 and likely others) | The actually-registered middleware is `Distribution/Middleware/AuthMiddleware.cs` (`app.UseMiddleware<AuthMiddleware>()` in Program.cs) — a plain, symmetric-key JWT check, NOT the RSA-based `Infra/Authorization/Middleware/AuthMiddleware.cs`/`JwtMiddleware.cs`, which despite their doc comments claiming to be "reference-only," are actually unregistered/dead. The active middleware reads `config["Jwt:Key"]`, but `appsettings.json` only defines `Jwt:PublicKey` (RSA XML, used by AuthHex-issued tokens) — so `Jwt:Key` is always null, the whole validation block is skipped, and `context.User` is never set for ANY request, valid token or not. It also never attaches `role_id`/`role_level`/`username` claims the way the dead Infra middleware does. Net effect: `ICurrentUserService.UserId`/`RoleId` are always null, so every `currentUser.UserId ?? throw new UnauthorizedAccessException()` check fails (this is the actual cause of bug #10, Procurement → Orders) and every permission/role-level check silently fails too | Decision: keep `Distribution/Middleware/AuthMiddleware.cs` (outside Infra) as the one true auth flow going forward; delete the dead unregistered duplicates `Infra/Authorization/Middleware/AuthMiddleware.cs` and `JwtMiddleware.cs`. Then fix the active middleware to validate against `Jwt:PublicKey` (RSA), reject (not silently swallow) invalid/missing tokens, and attach `role_id`/`role_level`/`username` claims from the local User/Role row after validation | 2026-09-02 |

## Resolved

| # | Area | Backend API Failure | Frontend Change Needed | Fixed In | Date |
|---|------|----------------------|--------------------------|----------|------|
| 1 | Operations → Rides (Create Ride) | Create Ride failed with "Vehicle not found" | — | Fixed DTO field naming mismatch | 2026-09-02 |
| 29 | Operations → Rides | Cancel-request API routes mismatched | Added View, Edit, and Cancel icons to Rides table | Fixed API routes + added action icons | 2026-09-02 |
| 30 | Operations → Delivery Tasks | Delivery task status update API mismatched | Added View, Confirm Delivery, and Mark as Failed icons | Fixed API routes + added action icons | 2026-09-02 |
| 32 | Sales (Create Sale, van sale) | If any item was short on the vehicle, the whole sale was rejected instead of selling what was available | — | Van sale now sells whatever quantity is on the vehicle per item and is always a clean Completed sale (no partial status) | 2026-09-03 |
| 33 | Operations → Rides (Close Ride) | No validation that meter end >= meter start | Close Ride dialog now enforces meter end >= meter start | Added backend + frontend validation | 2026-09-03 |
| 34 | Sales | — | No action icons on the Sales table | Added View and Cancel icons | 2026-09-03 |
| 2 | Operations → Loading Sheets | — | Missing View icon | Added View icon + details modal (status, dispatch/receipt confirmer + timestamps, item-level dispatched/received/resolved breakdown) | 2026-09-02 |
| 35 | Sales/Orders/Stores (scope-denied paths) | `Forbid()` crashed with `InvalidOperationException: No authenticationScheme was specified...` since no auth scheme is registered in Program.cs | — | Replaced all 6 `Forbid()` calls (SaleController, OrderController, StoreController) with `StatusCode(403)` | 2026-09-03 |
| 36 | Sales (Create Sale) — TEMPORARY workaround | Store-scope check and `currentUser.UserId` were always unresolved due to the broken auth middleware (#28), blocking every sale create | Added a required "Created By" user dropdown to the Create Sale modal | TEMP: bypassed store-scope check and added `CreatedByUserId` to `CreateSaleRequest` so the caller supplies it explicitly. Revert once auth (#28) is fixed | 2026-09-03 |
| 37 | Sales (Create Sale) | Every business-rule failure (store inactive, KYC threshold, price resolution failed, ride not found) silently returned a bare 403 with no explanation | — | Each failure now throws a specific `InvalidOperationException`, surfaced as a clear 400 error message in the create-sale toast | 2026-09-03 |
| 38 | Sales (Create Sale modal) | — | "Sale Summary" total box was frozen at Rs. 0 — `form.watch('items')` called inline doesn't subscribe the component to re-render on field changes | Replaced with `useWatch({ control, name: 'items' })`, which properly re-renders the total as items are entered | 2026-09-03 |
| 39 | Sales (Create Sale) | — | Moved Create Sale from a cramped modal to a dedicated `/sales/new` page: Sale Details and Items are each full-width, Items shown as an invoice-style table, and a compact Sale Summary card is right-aligned below the items | 2026-09-03 |
| 40 | Sales (Cancel Sale) — TEMPORARY workaround | `CancelAsync` still had the same broken store-scope check as Create (#36) — `HasStoreScopeAsync` always false due to broken auth middleware (#28), so cancel silently 404'd | — | TEMP: bypassed store-scope check in `CancelAsync`, same as Create. Revert once auth (#28) is fixed | 2026-09-03 |
| 3 | Sales (Create Sale) | Sale create always failed — `saleDate` was never sent, defaulted to year 0001, no price list ever active that date | Added a required Sale Date field to the Create Sale modal | Sent `saleDate` in the create payload; summary total was already computing correctly, just never reached the backend | 2026-09-03 |
| 4 | Orders | `GET /orders` returns a plain array with no pagination support, but the frontend client treated it as a paginated response (same bug class as delivery tasks, #30) | No action icons on the Orders table; store shown as a raw ID | Fixed API client to match the real response shape; added a View icon + details modal; store name now resolved and shown instead of the raw store ID | 2026-09-03 |
| 41 | Orders — TEMPORARY workaround | `UpdateAsync` had the same broken store-scope check as Delete/Sales (#28/#40) — always false, so status edits silently 404'd | Added Edit (status dropdown) and Delete icons to the Orders table, matching backend capability | TEMP: bypassed store-scope check in `OrderService.UpdateAsync`, same as `DeleteAsync`. Revert once auth (#28) is fixed | 2026-09-03 |
| 42 | Orders (Delete) | `GetAllAsync` filtered `.Where(o => o.IsActive)` — Delete sets `IsActive=false`, so a deleted order vanished from the list entirely (violated the Implementation Guide's own rule) instead of staying visible as Cancelled, and any further `PUT` on it correctly 404'd since `UpdateAsync` also checks `IsActive` | — | Removed the `IsActive` filter from `GetAllAsync` — deleted orders now stay visible in the table with a Cancelled badge | 2026-09-03 |
| 43 | Payments | — | Table and View modal showed raw Store ID and Collected By user ID instead of names | Resolved and now show store name and collected-by user's full name (fetched from `/stores` and `/users`) | 2026-09-03 |
| 5 | Payments (Record Payment) — TEMPORARY workaround, resolved for now | `PaymentService.CreateAsync` threw an uncaught `UnauthorizedAccessException` (`currentUser.UserId` always unset, #28) — controller only catches `InvalidOperationException`, so this was an unhandled 500, not a clean error; separately, `CreateFlatPaymentRequest` never accepted `StoreId`/`CollectedAt` at all, yet the form required typing a raw Store ID and picking a date, both silently discarded | Rebuilt Record Payment form: Sale picked from a dropdown (auto-derives store), removed the dead Store ID/Collected-At fields, added a required "Collected By" user dropdown; added a View icon + details modal to the Payments table | TEMP: added `CollectedByUserId` fallback to `CreatePaymentRequest`/`CreateFlatPaymentRequest`, same pattern as Sale (#36). **Payment creation now works end-to-end** with the user picking themselves manually. **Still to do once real auth (#28) lands**: drop the `CollectedByUserId` fallback and go back to `currentUser.UserId` only, and remove the "Collected By" dropdown from the form — see Future Fixes #7–#8 below | 2026-09-03 |
| 44 | Stores | — | Route column showed the raw Route ID instead of the route name (table and the Store detail page) | Resolved and now shown as the route name (fetched from `/routes`) on both the Stores table and `/stores/{id}` detail page | 2026-09-04 |
| 45 | Stores (map, dev only) | — | Any store page with the map (create/edit/view) crashed with "Cannot read properties of undefined (reading 'appendChild')" — react-leaflet's `MapContainer` doesn't support React Strict Mode's dev-only double-invoke of mount effects | Disabled `reactStrictMode` in `next.config.ts`. Dev-only issue; production builds never double-invoke effects so this was never a prod bug — restart the dev server to pick up the change | 2026-09-04 |
| 46 | Stores (Edit / Activate-Deactivate) | `UpdateStoreRequest` had no `IsActive` field at all — unchecking "Active" on the Edit Store page, and the Activate/Deactivate row action on the Stores table (both use `PUT /stores/{id}`), silently had no effect since the backend DTO dropped the field entirely | — | Added `IsActive` to `UpdateStoreRequest` and applied it in `StoreService.UpdateAsync` | 2026-09-04 |
| 47 | Stores (list/detail hid inactive) | `GetAllAsync` filtered `.Where(s => s.IsActive)` (same violation as Orders, #42) — after #46's fix actually started persisting the deactivation, the store just vanished from the list instead of showing Inactive; `GetByIdAsync`/`UpdateAsync` also blocked viewing or re-editing any already-inactive store, so it couldn't even be reactivated | — | Removed the `IsActive` filter from `GetAllAsync`; removed the `!IsActive` guards from `GetByIdAsync`/`UpdateAsync` so a deactivated store stays visible and can still be viewed/reactivated | 2026-09-04 |
| 48 | Stores (Activate/Deactivate row action, View visit history) | The table's Activate/Deactivate action sent only `{ isActive }` to `PUT /stores/{id}`, which requires the FULL record (RouteId, OwnerName, StoreName, etc. all required/non-nullable) — missing fields bound to C# defaults (`RouteId` → `Guid.Empty`), corrupting the store or failing an FK constraint; `GetVisitHistoryAsync` also still had the stale `!store.IsActive` guard, so any store corrupted/deactivated by the above would 404 on View Visit History too | — | Added a dedicated `PATCH /stores/{id}/status` endpoint (`StoreService.SetActiveStatusAsync`) that only touches `IsActive`; wired the row action to it instead of the full update; removed the stale `IsActive` guard from `GetVisitHistoryAsync` | 2026-09-04 |
| 49 | Stores (list pagination/filtering) | `GET /stores` accepted no query params at all and returned a plain array, while the frontend `serverSide: true` table + `stores.list({ routeId, kycStatus, search, page, pageSize })` callers (Stores table, Orders/Payments/Sale-new/Route-manage/Sales-Visits store pickers) expected real server-side filtering and a paginated response — pagination totals were broken and filters (including the route filter behind #6) were silently ignored | — | Implemented real filtering + pagination in `StoreRepository`/`StoreService`/`StoreController` (`routeId`, `kycStatus`, `search`, `page`, `pageSize`), returning a proper `PagedResponse<StoreResponse>` | 2026-09-04 |

## Future Fixes — Pending Real Auth

Everything below is a stopgap that only exists because `Distribution/Middleware/AuthMiddleware.cs` (see #28) never actually authenticates a request — `currentUser.UserId`/`RoleId`/`RoleLevel` are always unset. Once #28 is properly fixed (validate against `Jwt:PublicKey` via RSA, reject bad/missing tokens instead of silently skipping validation, and attach `role_id`/`role_level`/`username` claims from the local User/Role row), all of the following must be reverted/re-enabled:

1. **`SaleService.CreateAsync`** — restore the `HasStoreScopeAsync(request.StoreId)` check that was bypassed in #36.
2. **`SaleService.CancelAsync`** — restore the `HasStoreScopeAsync(sale.FK_StoreId)` check that was bypassed in #40.
3. **`CreateSaleRequest.CreatedByUserId`** (`SaleDTOs.cs`) — remove this field; `CreateAsync` should go back to using `currentUser.UserId` only (drop the `?? request.CreatedByUserId` fallback and the `InvalidOperationException` guard around it).
4. **Create Sale page** (`/sales/new`) — remove the "Created By" user dropdown and its form field/validation entirely; the acting user should come from the session, not be picked manually.
5. **`OrderService.UpdateAsync`** — restore the `HasStoreScopeAsync(order.FK_StoreId)` check that was bypassed in #41 (`DeleteAsync`'s equivalent check was bypassed earlier for the same reason).
6. **Sweep for the same pattern elsewhere** — `HasStoreScopeAsync`/`HasGlobalScope`-style checks exist in other services too (Store, etc., per #35's affected controllers) and likely have the same silent-fail behavior; audit and fix once auth is real, not just Sales/Orders.
7. **`PaymentService.CreateAsync` / `CreatePaymentRequest.CollectedByUserId`** (`PaymentDTOs.cs`) — remove this fallback field, same as Sale's `CreatedByUserId` (#5); go back to `currentUser.UserId` only.
8. **Record Payment form** (`payment-sheet.tsx`) — remove the "Collected By" user dropdown once auth is fixed.
9. **Re-verify `StatusCode(403)` usages from #35** — once real authentication exists, confirm whether any of those 6 call sites should become genuine ASP.NET `[Authorize]`-driven `403`/`401` responses instead of manual scope checks.

## Implementation Guide

Cross-cutting rules to apply consistently across every module/page while working through the entries above:

1. **Cancel / Delete semantics** — Cancel and Delete actions should never remove a row from the page. They should always set the record's status to Inactive (soft delete) and immediately reflect that updated status in the UI. The row must stay visible in the table after the action.
2. **Frontend validation** — On every page, check that form validation is handled per the actual business scenario (required fields, duplicate checks, valid ranges/formats) before submitting to the backend.
3. **Summary calculations** — Verify that any summary/total/aggregate calculations shown on a page (e.g. sale totals, stock summaries) compute and display correctly.
4. **UI consistency** — Maintain consistent layout, spacing, and interaction patterns across all pages.
5. **Icon consistency** — Use the correct, consistent icon set for actions (View/Edit/Delete/Cancel/etc.) across every page.
6. **Search & filters** — Check that the search bar and filters actually filter the table results, and that dropdown filters fetch their options correctly from the backend.