Yup a few fields gets you a long way, though I would recommend an audit log updated by triggers, rather than audit fields. For example on my CRUD rails app, we

Yup a few fields gets you a long way, though I would recommend an audit log updated by triggers, rather than audit fields. For example on my CRUD rails app, we use audit triggers in combination with setting a postgres local config variable with the username, the audit triggers pull the user info from the variables and record them into the DB. With a little more work I could probably also pull a backtrace of what line of code caused the trigger. Best part is because its all in the DB, if we rollback a transaction, the audit entries dont commit either. Because this stuff gets set in the application controller as an around filter it's all completely transparent to the devs. They just make ActiveRecord calls and the database records the queries, user, etc that made the change as well as storing all the changed fields into the audit log. Even if it's one of those update all commands.