25. Audit & Change History
[← Troubleshooting]/24-troubleshooting/ · [Index]/00-index/
25. Audit & Change History
Verified against: every audit-trail-related finding already made across this wiki, plus a direct search of the dashboard’s entire source tree for “audit” (zero matches — confirmed no audit-log feature exists anywhere in the admin).
What the brief wants, event by event
| Event | Real support |
|---|---|
| Product created | Not logged/visible after the fact — no audit trail on products ([Section 19]/19-product-editing/#what-should-be-audited-when-important-information-changes) |
| Product edited | Same — no history of edits, previous values are simply overwritten |
| Price changed | Same — see the Price row in [Section 19]/19-product-editing/#sensitive-changes |
| SKU changed | Same |
| Inventory adjusted | Same — confirmed in detail in [Section 5]/05-inventory-management/#receiving-new-stock (the Adjust Inventory screen has exactly one editable field, no reason/note) |
| Order status changed | Partial — the one real bright spot. Orders have a genuine Activity section: a system-generated timeline of status changes, plus a free-text comment box staff can use. See [Section 6]/06-stock-audit/#what-the-original-brief-wants-vs-what-exists for where this was first found, and [Section 8]/08-order-management/ for order status itself |
| Refund created | Partial. A refund captures a Reason (dropdown) and Note (free text) at the moment it’s created ([Section 15]/15-refunds-and-returns/#refund-processing) — real, but it’s captured once, not a change-history log you can review later for edits |
| Customer information changed | Not logged — no audit trail on customer edits ([Section 10]/10-customer-management/) |
| Coupon created | Not logged — Promotions have no audit trail either ([Section 11]/11-coupons-and-discounts/) |
| Settings changed | Not logged — no audit trail on Settings changes ([Section 2]/02-admin-dashboard/#settings) |
The one real precedent in this codebase
Worth restating plainly, since it matters for anyone scoping a future audit-trail feature: the Order Activity timeline + comment box is not a foreign concept to this codebase — it already exists, just scoped to Orders only. A real audit feature for Products/Inventory/ Customers/Settings would be extending an existing pattern, not inventing a new one.
What “each audit event should record” looks like today
The brief’s ideal (User, Action, Date/time, Previous value, New value, Reason) is only ever partially met, and only for two things:
- Order status changes — Date/time and the change itself are real (the Activity timeline); User and a structured Reason are not part of the automatic entries, though a staff comment can informally supply context.
- Refunds — Reason and Note are real and captured at creation; User and Date/time are implicit (whoever was logged in, whenever it happened) but not shown back on a change-history view.
Everything else on the brief’s list has none of these five properties captured anywhere.
Practical recommendation until a real feature exists
REQUIRED (process, not system-enforced): for anything not covered by the Order Activity timeline or a refund’s Reason/Note field — which is nearly everything — keep a manual record outside this admin (a shared log, a spreadsheet, whatever the business already uses) for any change to price, SKU, inventory, HSN/GST metadata, customer data, or settings. This has already been recommended piecemeal in [Section 5]/05-inventory-management/, [Section 6]/06-stock-audit/, and [Section 19]/19-product-editing/ — this section is the one place that states it as a single, system-wide gap.
[← Troubleshooting]/24-troubleshooting/ · [Index]/00-index/ · [Next: User Roles & Permissions →]/26-user-roles-and-permissions/