Step 1 — Choose what to audit (audit rules)

Open Audit ▸ Configuration ▸ Rules and create a record (one rule per model — the model is unique across rules).

The rule form also carries three tabs:

• PII Masking — Fields to Mask (PII). Values of these fields are masked when stored in audit lines (emails become a***@b***.c, phone numbers keep the country code and last two digits, everything else becomes ***).
• Approval Workflow — Sensitive Fields (require approval), Approver Group and Approval Timeout (hours) (default 72). See Step 4.
• Retention & Archive — Retention Days (0 = use the global autovacuum, 180 days by default) and Archive Target. See Step 6.

Click Subscribe in the header to activate the rule. The state moves to Subscribed and an Audit History shortcut is added to the Action menu of the audited model's form. Click Unsubscribe to stop logging; you must unsubscribe before changing the model, operations or masking/sensitive fields.

Faster starts:

• Audit Models (Configuration ▸ Audit Models) subscribes several models at once with the same settings.
• Compliance Presets (Configuration ▸ Compliance Presets) bootstraps GDPR, SOX or PCI-DSS in one click — it creates and subscribes the right rules with masking, sensitive fields and retention already filled in, and skips models that are not installed on your database.

Step 2 — Anomaly rules

Open Audit ▸ Security ▸ Anomaly Rules. An anomaly rule raises an alert when the number of matching audit events crosses a threshold inside a time window.

A cron (Audit anomaly — evaluate thresholds, every 5 minutes) walks the active rules. The Last evaluation fields show the last run time and event count. Breaches are deduplicated so you do not get repeat alerts inside the same window.

Step 3 — Alert rules, email and webhooks

An Alert Rule (Audit ▸ Alerts ▸ Alert Rules) matches a slice of the trail and raises an Alert. Combine Model, User, Method, Field and Keyword (the alert fires only when the changed values contain that keyword) to narrow it.

On the alert rule, the Notification Channels section controls how a match is shipped:

• Send Email — uses an email template (defaults to the bundled audit-alert template) and an optional comma-separated Email Recipients override. Mail is queued, not sent inline, so a slow SMTP server never blocks the user write that triggered the alert.
• Webhooks — one or more webhook records to call. Dispatch is queued (see Step 5).

To create a webhook, open Audit ▸ Configuration ▸ Webhooks.

Use the Send Test button to POST a synthetic payload and confirm connectivity before attaching the webhook to an alert rule. The form shows the last status, last call time and call count.

Step 4 — Approval workflow

Approvals turn a risky edit into a reviewed action. On an audit rule's Approval Workflow tab, add fields to Sensitive Fields (require approval), pick an Approver Group and set an Approval Timeout (hours).

From then on, when any user tries to write one of those fields, the write is blocked and a bf.audit.approval.request is created instead. Approvers find pending requests under Audit ▸ Approvals.

The request shows a side-by-side Current vs Requested diff. An approver in the group clicks Approve to apply the change for real, Reject to discard it, or Open Record to inspect the target. Requests left pending past the rule's timeout are auto-expired by an hourly cron (Audit approval — expire pending). If applying an approved change fails (the record was deleted, the value is invalid…), the request moves to Apply Error with the reason recorded.

Step 5 — Webhook queue

Webhook dispatch is asynchronous: when an alert fires, each webhook call is enqueued in Audit ▸ Configuration ▸ Webhook Queue and a cron (Audit webhook — drain queue, every minute) sends it with retry/back-off. This guarantees a slow or failing endpoint can never block the user write that triggered the alert. Each queue row shows its state (pending / sending / sent / failed), retry count and last error; Retry Now forces an immediate attempt.

Step 6 — Archive targets & retention

Logs are deleted on a schedule; archive targets let you keep a durable copy first. Create a target under Audit ▸ Configuration ▸ Archive Targets, then set it as the Archive Target on the relevant audit rule.

Use Send Test to ship one synthetic record and confirm the target works; the form records the last status, time and shipped count.

Retention is driven by two crons:

Both vacuums ship logs to their rule's archive target before deleting them, so a configured archive is always durable first.

Dashboard

Open Audit ▸ Dashboard. Pick a From / To window; the KPIs recompute live: Total Logs, Field Changes, Active Users, Triggered Alerts, Open Alerts, Pending Approvals, Logins OK and Logins Failed, plus the Top Model and Top User for the window.

The action bar drills into the same window: Open Logs, Timeline, Alerts and Approvals. Refresh reloads the figures.

Logs

Audit ▸ Audit Logs ▸ Logs lists every captured operation (default filter: last 7 days). Each row is one operation on one record; open it to see the Changed Fields tab with the before/after value of each field and a per-field diff preview.

Group by User, Model, Method, Type, User session or HTTP Request to slice the trail. The log form also links to its Alerts and a record-scoped Timeline. From the list, two server actions are available in the Action menu: Anonymize (GDPR) (managers only — wipes field values to *** but keeps the envelope) and Verify Hash Chain (confirms the tamper-evidence chain is intact). Log Lines (Audit Logs ▸ Log Lines) is the same data flattened to one row per field change. Export Logs writes a filtered range to XLSX.

Login events

Audit ▸ Security ▸ Login Events records every authentication attempt with IP, user agent, a hashed session token and (on failure) the reason — no rule needed. Rows are colour-coded: green for success, red for failed, amber for blocked.

Default filter is the last 7 days; filter by Success / Failed / Blocked or group by User, State or IP.

Timeline

Audit ▸ Audit Logs ▸ Timeline merges record events and individual field changes into one chronological stream. Each entry shows the time, user, method, model, the changed field (if any) and a summary with a change type of Added, Removed or Changed.

Use the Field Changes / Record Events filters to focus, or switch to the pivot view to chart events by day and model.

Patch upgrades (same series, e.g. 18.0.1.0.0 → later)

1. Back up your database and filestore first.

2. Replace the module folder with the newer build.

3. Restart Odoo with the module updated:

   ./odoo-bin -c your.conf -u bambooforge_audit_pro -d your_db
   

4. Odoo applies any schema/data changes automatically. Your existing records and configuration are preserved.

Cross-version migration (e.g. Odoo 17 → 18)

Upgrading Odoo itself is a database migration handled by Odoo's standard upgrade tooling. When you migrate the database to the next Odoo series, install the matching build of this module for that series. Data created by this module carries over with the database migration.

After any upgrade the module's scheduled actions resume on their normal cadence — no manual re-activation is required.

What is removed

• The module's own tables and every record in them (17 models, prefixed auditlog.*) — this is the data this module created.
• The menus, actions, views and reports this module installed.
• Its scheduled actions (cron jobs) — they stop immediately on uninstall.
• The security groups this module defined (user assignments to them are dropped).

What is preserved

• Your standard Odoo data (partners, products, sales, invoices, inventory moves) is not deleted — this module only reads and annotates it; the underlying records stay.
• Attachments and chatter messages on standard records are kept.

As always, take a database backup before uninstalling in production.

18.0.5.5.0

Current release for Odoo 18.0. This build includes:

• Contextual anomaly detection, one-click GDPR/SOX compliance attestation PDF and a daily tamper tripwire on top of hash-chained audit logs, alerts, webhooks, PII masking, approval workflow, retention policy and external archiving.

Feature additions and fixes ship as new builds on the Odoo Apps store; this page and the module's version reflect the current published release. Always keep the build matched to your Odoo series (see Upgrading & version compatibility).