From ad740747712d7ce09a165e2141794273b47415a1 Mon Sep 17 00:00:00 2001 From: DeepnaPooja Date: Thu, 3 Sep 2026 17:04:27 +0530 Subject: [PATCH] Update test bug log --- Distribution/docs/testbug.md | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/Distribution/docs/testbug.md b/Distribution/docs/testbug.md index 622e9aa..954c1f9 100644 --- a/Distribution/docs/testbug.md +++ b/Distribution/docs/testbug.md @@ -6,8 +6,6 @@ Running log of backend API failures found during testing and the corresponding f | # | Area | Backend API Failure | Frontend Change Needed | Date | |---|------|----------------------|--------------------------|------| -| 3 | Sales (Create Sale) | Sale create not working | Update the Create Sale modal UI |Sale summary calculation not display | Add view icon to the action | 2026-09-01 | -| 4 | Orders | | Add a View icon to the action column in Orders table | 2026-09-01 | | 5 | Payments (Record Payment) | Cannot add new payment | Add a View icon to the action column in Payments table | 2026-09-01 | | 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 | 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 | @@ -42,7 +40,30 @@ Running log of backend API failures found during testing and the corresponding f | 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 | + +## 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. **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