Addon nuevo para limpiar adjuntos de ramas de staging luego del tiempo de build
Staging Attachment Purge
Propósito
Elimina automáticamente los adjuntos (ir.attachment) de los modelos que elijas en las ramas de staging/dev de Odoo.sh, para que esas ramas nazcan "aligeradas" sin el filestore histórico que infla el almacenamiento facturado.
Contexto / Por qué
En Odoo.sh cada rama de staging/dev es una copia completa de producción, filestore incluido. Cuando unos pocos modelos acumulan mucho filestore (por ejemplo los adjuntos de stock.picking), cada rama de staging arrastra ese peso y se factura encima de producción. Este módulo elimina los adjuntos de los modelos configurados en staging/dev —y solo ahí—, recuperando tanto las filas de la base de datos como los archivos físicos.
Salvaguardas (nunca toca producción)
Dos protecciones independientes; la purga solo corre si ambas pasan:
- Flag de neutralización (principal). Solo actúa si database.is_neutralized está activo. Odoo.sh siempre neutraliza las bases de staging y dev, y nunca producción, así que es una garantía a nivel de plataforma que no requiere configuración y funciona en cualquier instancia.
- Blocklist de producción (opcional, secundaria). Lista separada por comas de nombres de base de datos que nunca deben purgarse. Se configura por instancia donde quieras la red extra; nunca se sube al repositorio, así el mismo addon sirve para múltiples clientes.
Cómo funciona
- La lógica vive en ir.attachment y se expone como un método @api.autovacuum. El cron de autovacuum queda activo tras la neutralización, así que la purga corre automáticamente en staging/dev sin intervención manual. En producción la salvaguarda corta de inmediato.
- El borrado usa SQL crudo por lotes en vez de unlink() (que sería lento con cientos de miles de registros y enrutaría el borrado de archivos por el checklist del recolector). Los store_fname se capturan antes de borrar, para tocar únicamente esos archivos físicos después — sin escanear todo el filestore.
- Un archivo se conserva si algún adjunto sobreviviente lo sigue referenciando, respetando la deduplicación de contenido del filestore.
Configuración
En Ajustes → Staging Attachment Purge (requiere el grupo Ajustes / Administración):
- Estado de la base de datos — un badge que indica si la base actual está neutralizada (staging/dev, purga permitida) o es producción (bloqueada).
- Purgar adjuntos en staging — interruptor principal on/off.
- Modelos a purgar — los modelos cuyos adjuntos se eliminan (ej. stock.picking).
- Purgar ahora — ejecuta la purga de inmediato (con las mismas salvaguardas), sin esperar al cron de autovacuum. Devuelve una notificación con la cantidad de adjuntos y archivos eliminados.
La configuración se guarda en ir.config_parameter:
| Clave | Significado |
|---|---|
| plus_staging_attachment_purge.active | Interruptor principal (True/False). |
| plus_staging_attachment_purge.model_names | Nombres de res_model a purgar, separados por comas. |
| plus_staging_attachment_purge.production_db_names | Blocklist opcional de nombres de BD de producción. |
Las ramas nuevas nacen aligeradas
Como el módulo viaja en la base de código de la que se forkean las ramas de staging/dev, cada rama nueva lo hereda y aplica la purga por sí sola — sin ningún paso manual por rama.
Notas
- La purga corre desde el cron de autovacuum, no durante el build, así que no ralentiza el build de staging. El almacenamiento se recupera dentro del ciclo de autovacuum una vez la rama está arriba (usa Purgar ahora para recuperarlo al instante).
- El borrado es irreversible sobre la base objetivo (staging). Está diseñado para no correr nunca en producción, pero revisa las salvaguardas antes de activarlo.
Ficha técnica
- Versión: 17.0.1.0.0
- Licencia: LGPL-3
- Depende de: base, base_setup