server configuration environment files

Por sí solo, este módulo hace poco. Véase por ejemplo el addon mail_environment que depende de este para permitir configurar los servidores de correo entrante y saliente según el entorno.

Puede almacenar sus valores de configuración en un módulo complementario llamado server_environment_files. Puede copiar y personalizar el módulo server_environment_files_sample proporcionado para este propósito. Alternativamente, puede proporcionarlos en variables de entorno SERVER_ENV_CONFIG y SERVER_ENV_CONFIG_SECRET.

Para configurar este módulo, debe editar el archivo de configuración principal de su instancia y añadir una directiva llamada running_env. Los valores comúnmente usados son 'dev', 'test', 'production':

[options] running_env=dev

O establecer la variable de entorno RUNNING_ENV o ODOO_STAGE. Si ambos están establecidos, el archivo de configuración tendrá prioridad sobre el entorno y RUNNING_ENV sobre ODOO_STAGE.

ODOO_STAGE se usa para la plataforma odoo.sh donde no podemos establecer RUNNING_ENV, los valores posibles observados son production, staging y dev

Los valores asociados a claves que contienen 'passw' solo se muestran en el entorno 'dev'.

Si no proporciona ningún valor, se usa test como valor predeterminado seguro.

Tiene varias posibilidades para establecer valores de configuración:

server_environment_files

Puede editar la configuración que necesite en el addon server_environment_files. El server_environment_files_sample se puede usar como ejemplo:

• los valores comunes a todos / la mayoría de los entornos se pueden almacenar en el directorio default/ usando la sintaxis de archivo .ini;
• cada entorno que necesite definir se almacena en su propio directorio y puede sobrescribir o extender los valores predeterminados;
• puede sobrescribir o extender valores en el archivo de configuración principal de su instancia;

Variable de entorno

Puede definir la configuración en la variable de entorno SERVER_ENV_CONFIG y/o SERVER_ENV_CONFIG_SECRET. Las 2 variables se manejan exactamente de la misma manera, esto es solo una conveniencia para el despliegue donde puede aislar los secretos en un archivo diferente y cifrado. Son variables de entorno multilínea en el mismo formato configparser que los archivos. Si usó opciones en server_environment_files, las opciones establecidas en la variable de entorno las sobrescriben.

Las opciones en la variable de entorno no dependen de running_env, el contenido de la variable debe establecerse de acuerdo con el entorno de ejecución.

Ejemplo de configuración:

Un archivo público, que contendrá variables públicas:

# These variables are not odoo standard variables, # they are there to represent what your file could look like export WORKERS='8' export MAX_CRON_THREADS='1' export LOG_LEVEL=info export LOG_HANDLER=":INFO" export DB_MAXCONN=5

# server environment options export SERVER_ENV_CONFIG=" [storage_backend.my_sftp] sftp_server=10.10.10.10 sftp_login=foo sftp_port=22200 directory_path=Odoo "

Un segundo archivo que está cifrado y contiene secretos:

# This variable is not an odoo standard variable, # it is there to represent what your file could look like export DB_PASSWORD='xxxxxxxxx' # server environment options export SERVER_ENV_CONFIG_SECRET=" [storage_backend.my_sftp] sftp_password=xxxxxxxxx "

ADVERTENCIA

> my_sftp debe coincidir con el nombre del registro. Si desea algo más > fiable use server.env.techname.mixin y use el campo tech_name para > referenciar registros. Consulte "USAGE".

Valores predeterminados

Cuando se usa el mixin server.env.mixin, para cada campo calculado por entorno, se crea un campo compañero <field>_env_default. Este campo no depende del entorno. Es un valor de reserva usado cuando no se establece ninguna clave en los archivos de configuración / variable de entorno.

Cuando se usa el campo predeterminado, el campo se hace editable en Odoo.

Nota: las claves de entorno vacías siempre tienen prioridad sobre los campos predeterminados

Integración del entorno del servidor

Lea la documentación de la clase models/server_env_mixin.py y [models/server_env_tech_name_mixin.py] (models/server_env_tech_name_mixin.py)

Puedes incluir un mixin en tu modelo y configurar los campos calculados por env mediante una sobrescritura de _server_env_fields.

class StorageBackend(models.Model): _name = "storage.backend" _inherit = ["storage.backend", "server.env.mixin"]

@property def _server_env_fields(self): return {"directory_path": {}}

Lee la documentación de la clase y los métodos en models/server_env_mixin.py.

Si quieres tener un nombre técnico al que hacer referencia:

class StorageBackend(models.Model): _name = "storage.backend" _inherit = ["storage.backend", "server.env.techname.mixin"]

[...]

Restaurar columnas al desinstalar

Cuando server.env.mixin está vinculado a un modelo existente, el ORM elimina las columnas almacenadas originales de todos los campos gestionados por env. Si el addon de vinculación se desinstala posteriormente, esas columnas deben recrearse para que la base de datos siga siendo utilizable.

Añade un uninstall_hook a tu addon y delega en restore_env_managed_columns:

# your_addon/__init__.py from ./hooks import uninstall_hook # your_addon/hooks.py from odoo.addons.server_environment import uninstall

def uninstall_hook(env): uninstall.restore_env_managed_columns( env, "storage.backend", ["directory_path", "other_field"], )

# your_addon/__manifest__.py { "uninstall_hook": "uninstall_hook", }

El helper crea cualquier columna que falte (idempotente: seguro de llamar varias veces) y las repuebla con el valor efectivo actual de cada registro — ya provenga ese valor de un archivo de configuración de entorno o del campo predeterminado almacenado (x_<field>_env_default).

El hook debe ejecutarse antes de que se eliminen las extensiones del ORM, lo cual está garantizado por la secuencia de desinstalación de Odoo (los hooks se ejecutan antes de Module.module_uninstall()).

Manejo de campos obligatorios

Si una columna restaurada es obligatoria (tiene una restricción NOT NULL) pero no tiene valor efectivo (falta en la configuración de entorno y no hay campo predeterminado establecido), la restauración fallará con un UserError.

Solución: pasa un diccionario field_defaults con valores de reserva:

def uninstall_hook(env): restore_env_managed_columns( env, "ir.mail_server", ["smtp_host", "smtp_authentication"], field_defaults={ "smtp_authentication": "login", # fallback for required field }, )

El helper usará el valor de reserva si se proporciona y el valor del campo calculado está vacío. Si no se proporciona ningún valor de reserva pero un campo obligatorio no tiene valor, se lanza un UserError con instrucciones sobre cómo proporcionar un parámetro field_defaults.

Migrar al eliminar la dependencia de server_environment

Al refactorizar un addon existente que incorpora una vinculación server.env.mixin, es posible que quieras extraer la vinculación a un addon glue separado y eliminar la dependencia server_environment del original. Esto mantiene el addon base ligero mientras preserva las características de server-environment para quienes instalan el addon glue.

Patrón:

• Addon original (v1): depende de server_environment y vincula el mixin directamente en el código del modelo.
• Addon refactorizado (v2): elimina server_environment de las dependencias, elimina la vinculación del mixin y la herencia del modelo ORM relacionada.
• Nuevo addon glue (opcional, misma versión): depende tanto de server_environment como del addon original v2; vuelve a añadir la vinculación del mixin en un archivo de módulo separado.

Lista de verificación de la migración:

• En el __manifest__.py v2 del addon original:
• Elimina "server_environment" de depends.
• Elimina el/los archivo(s) de modelo que contenían la vinculación del mixin.
• Actualiza depends para añadir el nuevo addon glue si el addon base todavía lo necesita (en caso contrario, haz que el addon glue sea opcional para los usuarios que quieran env-binding).
• En el código del modelo v2 del addon original:
• Elimina o simplifica la clase de modelo que heredaba de server.env.mixin.
• Si el modelo solo estaba ahí para la vinculación, elimínalo por completo.
• Restaura las definiciones de campo originales (no como campos calculados).
• Crea un script de migración (si es necesario) para restaurar las columnas durante la actualización del addon, antes de que se descarguen las extensiones del modelo ORM. Usa un hook @post_load o un script de migración dedicado: # migrations/18.0.1.0.0/post-restore-columns.py def migrate(cr, version): # Call the restoration logic while the v1 model is still active env = odoo.api.Environment(cr, odoo.SUPERUSER_ID, {}) # If any field is required and may have no value in the environment, # provide a fallback via field_defaults restore_env_managed_columns( env, "storage.backend", ["directory_path", "other_field"], field_defaults={ "directory_path": "/tmp", # fallback for required field }, )
• Crea el addon glue con la re-herencia del modelo: # your_addon_env/__init__.py from . import models # your_addon_env/models/__init__.py from . import storage_backend # your_addon_env/models/storage_backend.py class StorageBackend(models.Model): _name = "storage.backend" _inherit = ["storage.backend", "server.env.mixin"] @property def _server_env_fields(self): return {"directory_path": {}} # your_addon_env/__manifest__.py { "name": "Storage Backend – Server Environment", "version": "18.0.1.0.0", "depends": ["server_environment", "storage_backend"], "installable": True, }

Puntos clave:

• La restauración de columnas debe ocurrir durante la actualización del addon (paso 3), no como un hook de desinstalación, porque la vinculación del modelo original sigue activa.
• El helper restore_env_managed_columns es idempotente y seguro de llamar incluso si las columnas ya existen.
• Los usuarios que no necesitan las características de server environment simplemente no instalan el addon glue—el addon base sigue funcionando con columnas de base de datos simples.
• Los usuarios que sí necesitan server environment pueden instalar tanto el addon base (v2+) como el addon glue (misma versión) para recuperar la vinculación.