OCA
Create a neutralized database backup
Currently, it is possible to create a DB backup and restore it by checking the 'neutralize' option.
However, this can't be done during the backup creation.
In some cases, it will be beneficial for the backup itself to be 'neutralized' to prevent misconfiguration during the restoration process in test environments.
I can work on a solution to extend the default /web/database/backup controller
I'm not sure if is best to first create the backup and then neutralize offline or to create a neutralized copy of the current DB and backup that.
I haven't needed this feature yet in Odoo, so I've quickly read up on https://www.odoo.com/documentation/17.0/administration/odoo_sh/getting_started/branches.html#staging
I'm not sure if is best to first create the backup and then neutralize offline or to create a neutralized copy of the current DB and backup that.
Neutralizing on import is what I have done in the past for the non-Odoo CRM that I support. It doesn't interfere with existing production database backups, which are automated and rock solid.
In some cases, it will be beneficial for the backup itself to be 'neutralized' to prevent misconfiguration during the restoration process in test environments.
Could you describe these cases?
Sure, I'm thinking in the scenarios when you need to send your DB to another person, generally someone in training, and want to be sure that he wont uses a "production" environment, similar as what odoo.sh does.
Is more a "safety net"
Sure, I'm thinking in the scenarios when you need to send your DB to another person, generally someone in training, and want to be sure that he wont uses a "production" environment, similar as what odoo.sh does.
We have a configuration-managed process that does pretty much what Odoo.sh does; our employees can generate a staging server with neutralized data, without ever having had access to production data. That said, I'm trying to move away from neutralized data, intending to fully utilize odoo populate ^1 for developer and tester environments.
Yea, I have the same opinion, but, in some cases is useful to have the "almost same" production environment for test.
For example, in latin american accountability, the invoices are sent to external systems. Is necessary to "neutralize" this to prevent sending that information. But, a "demo" DB will not work, in this same example, the "bug" trying ti resolve may be difficult to reproduce, maybe is something with the tax config, or the prices, or the EDI generation, etc.
+1 on the issue. Having sometimes a backup from an environment that is neutralized is a better approach for specific testing when compared with a populated database.
