Ticket 67993 (4) — Proposals for `odoo-db`

[dzungtran89]

The ticket asks one question:

Should we add a generic db_cleaning.sql / anonymize.sql to odoo-db, or
rely on odoo neutralize only?

Cleaning — the part worth adding

Cleaning splits into two layers (this is already stated in (3)):

• Generic layer — identical across every Odoo project: crons off, mail/fetch
  servers gone, queue jobs cleared, passwords reset, enterprise subscription
  reset. Safe to run on any non-prod copy.
• Per-instance tail — report.url, web.base.url, mail catchall domain,
  connector credentials. Differs per environment → lives in
  .trobz/db_cleaning_{instance}.sql.

odoo-db should own the generic layer as odoo-db clean; the per-instance
tail stays in the project script (applied via --script)

Neutralize and Anonymization

1. Neutralize is module-level → already covered by $ odoo neutralize.
   odoo-db should not duplicate it, but it can already tell us a DB is
   un-neutralized.
2. Anonymization is schema-specific → a generic anonymize.sql would be
   actively harmful (false confidence). odoo-db's contribution should be
   auditing, which is what the tool already does best.

That linked anonymize_database.sql is a fine per-project starting template,
but wrong as a built-in: it covers standard tables only and mixes all four
operations (1) in one file.

What odoo-db can add for anonymization:

Two non-generic, genuinely useful contributions, both in the tool's existing
audit lane:

• odoo-db clean --script <project_anon.sql> — same runner as cleaning;
  odoo-db executes a project-owned anonymization script but never ships one.
• A PII-candidate audit (the high-value idea): scan the schema for columns
  that look like PII — by name (email, phone, vat, name, street,
  mobile, iban, …), by type, and across custom/Studio tables (it already
  surfaces Studio + not-odoo objects) — and emit a checklist of columns an
  author must decide on. It auto-generates a "columns you probably need to
  anonymize" checklist from the schema, changes no data, and is safe to share
  because it only contains column names.

Suggested next step for the odoo-db repo

Smallest useful slice first:

1. odoo-db clean <db> — generic cleaning layer + --script to apply a project
   file, with a production guard and a per-table change summary.
2. A "cleaned?" indicator alongside the existing neutralization status in list.
3. (Later) anon_candidates in prepare-audit — the PII-column checklist.