Auditing

Think of it as

Think of it as three tiers you climb only as far as the questions require. The first tier is timestamps. `auto_now_add=True` sets a field once on creation and `auto_now=True` updates it on every save, which covers "when" for free. The catch is in the word *save*: both are applied during `Model.save()`, so any path that bypasses `save()` bypasses them — and `QuerySet.update()` does exactly that, running one SQL statement and, as Django's documentation states, running no `save()` methods and emitting no `pre_save`/`post_save` signals. So a bulk update leaves `updated_at` showing a date before the change it made, which is worse than having no field at all because it looks authoritative. When you use `update()` deliberately, set the timestamp in the same call. The second tier is actors, and the obstacle is structural: a model has no idea who is logged in, because the ORM has no access to the request. The two honest options are to pass the actor explicitly into a service function — verbose, and completely clear about where the value came from — or to put the current user in a `ContextVar` set by middleware and read it in `save()`, which is convenient and has the well-known failure that anything running outside a request (a management command, a Celery task, a migration) has no user, so the field must be nullable and the code must cope. Prefer explicit passing for anything that matters. The third tier is history, and the trigger for climbing to it is precise: you need it when a question involves *more than one* change. "Who set the price to £49?" is answerable from `updated_by` only if nobody has touched the row since. "How long was this order in processing?", "who approved it before it was rejected?", "what did this look like in March?" are all unanswerable from a current-state field by construction, no matter how many actor columns you add. A row per change — with the previous value, the new value, the actor and the time — answers all of them, and once it exists the four fields become a convenient cache of the latest row rather than the record itself.

Think of it as

Sort them by who asks the question and how long the answer must survive, and the differences become concrete rather than philosophical. An application log is read by you, this week, while something is broken; volume is enormous, precision about *who* is often unnecessary, and thirty days of retention is usually generous. An audit log is read months or years later by a compliance officer, a customer's lawyer, or an incident reviewer, and the questions are always the same shape: which human, which action, which object, when, and from where. That audience changes the engineering. It must be append-only, because an audit trail that can be edited proves nothing; it must be complete for the actions it covers, because a gap is indistinguishable from a cover-up; and it cannot live only in a log-shipping pipeline that drops messages under load. Business event history is different again: it is *part of the domain*, not an observation of it. "This order was cancelled on the 3rd, refunded on the 5th" is something the product itself needs — to render a timeline, to compute a refund window, to answer a support question — so it belongs in your database, is queried by ordinary application code, and outlives any logging decision. The starting point most projects actually need is smaller than a full audit system, and it is the roadmap's first two items: `created_at`/`updated_at`, and `created_by`/`updated_by`. Those cost almost nothing and answer a surprising share of real questions. They also have a specific limitation worth knowing before relying on them: `auto_now`/`auto_now_add` are applied during `save()`, and `QuerySet.update()` bypasses `save()` entirely — so a bulk update leaves `updated_at` stale, and any audit built on model signals misses the same writes. The last distinction is what an audit row should store. Storing a full before-and-after copy of the object is tempting and usually wrong: it duplicates data you already have, and it copies personal data into a store you keep for seven years. Store the *diff* — which fields changed, and to what — and for sensitive fields store only that they changed.

Think of it as

Ask what question the row will be used to answer, and audit the events that appear in those questions. Three questions recur. "Was this account compromised?" needs the security events, and specifically needs the *failed* attempts too — a successful login is unremarkable on its own and becomes evidence when it follows forty failures from a new country. "Did staff do something they should not have?" needs administrative actions, which is a different category from ordinary user activity because the actor is not the data subject; support looking at a customer's record is a legitimate action that must still be attributable. Django already gives you part of this for free — `user_logged_in`, `user_logged_out` and `user_login_failed` signals, and `django.contrib.admin`'s own `LogEntry` for additions, changes and deletions made through the admin — and the mistake is assuming that coverage extends to your own staff tooling, which it does not. "Where did this money go?" needs payment events, and money is the category where the audit trail is not optional at any scale: every transition, with the provider reference and the amount, because reconciliation and disputes both depend on it. Data access logging is genuinely different and deserves an explicit decision rather than a default. Recording every read is what lets you answer "who looked at this patient record?", and in regulated contexts that is a requirement. Everywhere else it is expensive in a way that compounds: reads outnumber writes by orders of magnitude, so the audit table can grow faster than the data it describes, and a synchronous write on every read adds latency to your hottest path. The workable middle is to scope it — log access to the specific data that warrants it (a customer's payment details, a patient record, an export of many records), not to every page — and to treat *bulk* access differently from single-record access, because one person reading one record is normal and one person reading ten thousand is the thing you actually want to detect.