Store server env defaults by env name

[simahawk]

Is your feature request related to a problem?

Today, when a field is made configurable via env you can still edit values manually.
These values are stored into server_env_defaults.
If you don't have env overrides such values will be used in all envs, which means that by restoring a prod db on staging you might have a prod conf in the wrong place.
This can easily happen when you leave to customers or to consultants the possibility to create new records manually (eg: add a new webservice to call on the fly).

Example of values today:

{"destination_pwd_env_default": "xyz", "destination_url_env_default": "https://send-somewhere.com"}

Describe the solution you'd like

Values from default should be mapped by environment. This way, we can lookup values by specific env.

Example of values in the future:

{
    "prod": {
        "destination_pwd_env_default": "xyz", "destination_url_env_default": "https://send-somewhere.com"
    }
}

Describe alternatives you've considered

Any?

@guewen @gurneyalex @sebalix your input is appreciated :)

[florian-dacosta]

AFAIK, this problem is solved by server_environment_data_encryption.

The main goal of server_environment_data_encryption was actually to be able to configure the env values from the UI instead of from the config files on the server, so it has been made to store the value of each env in the database. (and that is also why all is crypted, because the secrets are also made to be stored in the database.)
Note that is it still compatible with server env value from configuration files on the server).

The ideal is the following :
On the production server, define the encryption key of all your environments.
On the other servers (preprod, dev, etc) define only the encryption key of the concerned environment.

Then, from your production, you'll be able to configure in Odoo the value for each environments, and from the other environment, you'll only be able to read the value of its own environment.

[guewen]

The customisation of a field is blocked if the field is defined in an environment file / envvar. The idea was to allow modules to declare fields as "dependent on the environment", then to let the integrator choose exactly what is shared or not:

• Not set in a file/envvar : value can be set in DB and therefore shared between ends
• Set in "base" env file with no value: must be set in an env file/envvar, edition blocked
• Set in env file/env file, value will be used in corresponding env

I remember that we actually wanted to share the "default " value between environments, but I don't remember the exact use case.

Just bear in mind that we would lose this ability to choose if a field must be shared or not.

[simahawk]

@florian-dacosta thanks for your feedback.
Since years I wanted to check how the 2 modules worked together... good to know!
I'll have a look into it.

Then, from your production, you'll be able to configure in Odoo the value for each environments, and from the other environment, you'll only be able to read the value of its own environment.

Sounds interesting. I guess that I can still edit the values for each environment from each env too?

Question: how does it work w/ existing data? Can we safely install the module after setting env keys?
I guess we'll have to force re-write all the values that have been added manually (?)

@guewen thanks for your feedback

I remember that we actually wanted to share the "default " value between environments, but I don't remember the exact use case.

Over the time it drove us to several issues as long as we granted the user the freedom to manage some conf (which prevents us to be a bottleneck for doing things).

Just bear in mind that we would lose this ability to choose if a field must be shared or not.

I'm not sure this is really desirable. However, server_environment_data_encryption seems to allow to define them beforehand.

[florian-dacosta]

Sounds interesting. I guess that I can still edit the values for each environment from each env too?

Yes each environments can read/edit its own value, but if you edit a value on your preprod environment, you will loose it at next database refresh from prod, that is why the idea is to set every thing from production.

Question: how does it work w/ existing data? Can we safely install the module after setting env keys?
I guess we'll have to force re-write all the values that have been added manually (?)

The module has no pre/post install hook, I thought about it but we did not actually use these default env value from database, so we did not really need this migration logic.
I guess it could be added though, re-writing all the value indeed, for each environment.

[github-actions]

There hasn't been any activity on this issue in the past 6 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 issue to never become stale, please ask a PSC member to apply the "no stale" label.