[14.0][ADD] base_anonymize

[hbrunn]

This module provides a flexible mechanism and default configuration for
anonymizing data in an Odoo database.

Use Cases / Context

This module was developed because the OCA internal tools workgroup needs
access to the OCA database, but shouldn't have access to the data of OCA
members.

It should be useful in any setting where external developers need access
to a database, or for setting up test instances.

Configuration

To configure this module, you need to:

1. Go to Settings / Technical / Anonymization / Field Definitions
2. Review fields to overwrite, every field can be overwritten by some
   method, and the overwritten records can be restricted by a domain

Usage

To use this module, you need to:

1. Go to Settings / Technical / Anonymization / Run Anonymization
2. Confirm you really mean it

The above is only for testing configurations, usually you would script
this in some export setting by installing the module on a clone,
possibly a custom module modifying the field configuration, and running
the code env['anonymize.wizard'].action_run() before you export your
file store and dump the database to wherever you need it.

!!CAUTION!! The default configuration overwrites the database secret
and sets all passwords to password - for your tests, you will want
to disable the field definitions for res.users and
ir.config_parameter, because you'll be logged out after the
anonymization run otherwise.

[legalsylvain]

Fyi odoo/odoo#156944

[petrus-v]

@hbrunn thanks for this works,

I've a similar requirement on an customer instance, would you accept if I improve it a bit in a way that all string base field in the database would be anonymisation by default with anonymize.method.random.string method. We could create a anonymize.method.no_op method to discard some anonymisation on dedicated fields, and, probably declare a list of models to ignore as well (ie: ir.config_parameter, ...). I've the feeling it's more secure to anonymise every things by default, to avoid data leak issue (ie: while updating dependency module that would add a new related store field) ?

Generally speaking I don't feel very safe to have method that can corrupt production data in the production environnement, maybe if I had to write it from scratch I would have write it in a click-odoo script with a config file that wouldn't be store in the database itself. What do you think?

Finally I'm wondering if server-tools repository would be a better candidate for such modules ?

[hbrunn]

@petrus-v I think what you describe is a different addon/script, so I'd rather suggest you do this as it fits you independent of this PR.

I designed the module the way it is so that it's viable for users having only access to the Odoo UI. And you don't need to install it in production, you can and should do an export of some configuration generated on a clone (or as the readme suggest add this in an own module), install it during your test instance creating pipeline, import the configuration, and run the anonymization there exclusively.

Ideally, it will contain the configuration for every privacy relevant field defined by OCA modules anyways, so you don't need to configure anything if you don't use custom modules.

A word of caution for your every char field approach: If you do that on sql level, you'll screw up reference and selection fields. If you go via the ORM, it will be horribly slow and run into a plethora of constraints. And you absolutely need to anonymize ir.config_parameter database.secret.

As for which repository, I don't mind much, can just as well move this to server-tools.

[petrus-v]

@petrus-v I think what you describe is a different addon/script, so I'd rather suggest you do this as it fits you independent of this PR.

I designed the module the way it is so that it's viable for users having only access to the Odoo UI. And you don't need to install it in production, you can and should do an export of some configuration generated on a clone (or as the readme suggest add this in an own module), install it during your test instance creating pipeline, import the configuration, and run the anonymization there exclusively.

Ideally, it will contain the configuration for every privacy relevant field defined by OCA modules anyways, so you don't need to configure anything if you don't use custom modules.

A word of caution for your every char field approach: If you do that on sql level, you'll screw up reference and selection fields. If you go via the ORM, it will be horribly slow and run into a plethora of constraints. And you absolutely need to anonymize ir.config_parameter database.secret.

As for which repository, I don't mind much, can just as well move this to server-tools.

Thanks for your prompt and relevant answers. Let's go to weekend thinking about all of this 😎 !

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.