[UPD] Copilot instructions

Author: adhoc-cicd-bot

.github/copilot-instructions.md

@@ -31,6 +31,7 @@
 
    * Si ya existe un docstring, puede sugerirse un estilo básico acorde a PEP8, pero **no será un error** si faltan `return`, tipos o parámetros documentados.
 5. No proponer cambios puramente estéticos (espacios, comillas simples vs dobles, orden de imports, etc.).
+6. Mantener el feedback **muy conciso** en los PRs: priorizar pocos puntos claros, evitar párrafos largos y no repetir el contexto que ya está explicado en la descripción del PR.
 
 ---
 
@@ -104,48 +105,175 @@
 * En operaciones masivas, promover writes vectorizados y recomputes en lotes; en v19 se pueden combinar con `env.cr.commit()` controlado o helpers de progreso (`_commit_progress`) cuando el diff ya manipula crons.
   * Ejemplo sugerido: `partners.write({'comment': 'Actualizado masivamente'})` y `_commit_progress(processed=len(partners))` en jobs largos.
 * Recordar que estas prácticas no solo mejoran performance: al mantenerse dentro del ORM se heredan los controles de acceso, auditoría y reglas multi-compañía.
+* Tener en cuenta la **navegación de campos relacionales** en Odoo: acceder a campos encadenados como `m.fiscal_position_id.l10n_ar_tax_ids` es seguro incluso cuando `fiscal_position_id` está vacío (devuelve un recordset vacío). Por eso, expresiones como `not m.fiscal_position_id.l10n_ar_tax_ids` ya cubren el caso en que no haya posición fiscal y **no hace falta** añadir un chequeo previo separado sobre `fiscal_position_id`.
+* Revisar accesos directos por índice en listas o recordsets, por ejemplo `lines[0].id`: si el conjunto está vacío puede lanzar `IndexError`. Copilot debe sugerir patrones más seguros (por ejemplo `if lines: first = lines[0]`) o, cuando sea posible, reescribir la lógica para trabajar sobre el recordset completo en lugar de un único elemento.
 
 ---
 
-## Cambios estructurales y scripts de migración – **cuestiones generales (v18+v19)**
+## Cambios estructurales y scripts de migración – **cuestiones generales**
 
-Las mismas reglas generales descritas en la sección de Odoo 18 se aplican también aquí. Copilot debe reutilizar la misma lógica para decidir si pide migración o no:
+Cuando el diff sugiera **cambios de estructura de datos**, **siempre evaluar** si corresponde proponer un **script de migración** en `migrations/` (pre/post/end) **y recordar el bump de versión**.
 
-1. Renombres de campos **almacenados** y de modelos.
-2. Cambios de tipo con impacto real en la representación en DB (no para `Char → Text` u otros cambios triviales).
-3. Eliminación de campos con reestructuración de datos.
-4. Nuevos campos `compute` con `store=True` que requieren backfill, con advertencias en modelos muy grandes.
-5. Cambios de dominios o **eliminación/renombre** de valores de `selection` (añadir keys nuevas no requiere script en general).
-6. Cambios o adición de `_sql_constraints` / índices con riesgo de conflicto con datos existentes (al menos emitir **advertencia**).
-7. Cambios en `ir.model.data` / XML IDs, especialmente con `no_update="1"` cuando el contenido lógico cambia (sugerir forzar el cambio).
-8. Cambios de reglas de acceso / propiedad que requieran recalcular ownership o multi-company.
+### Reglas generales de estructura de `migrations/`
 
-En caso de duda, Copilot debe:
+* La carpeta dentro de `migrations/` debe corresponder con la versión declarada en el manifest (p. ej. `migrations/19.0.1.0/`).
+* Los scripts deben ser idempotentes, trabajar en lotes y registrar logs claros.
 
-* describir el riesgo,
-* sugerir un posible enfoque de migración,
-* pero **no exagerar**: si el cambio es claramente no rompedor (ej. añadir un valor extra de `selection` sin tocar los anteriores), no pedir migración.
+### Ejemplos de cambios estructurales (actualizado con tus criterios)
+
+En estos casos **normalmente corresponde** proponer migración (salvo notas en contra):
+
+1. **Renombrar campos o modelos**
+
+   * **Campos:** proponer migración **solo si el campo es almacenado** en base de datos:
+     * campos normales (`Char`, `Many2one`, `Boolean`, etc.),
+     * campos `compute` con `store=True`.
+     * Campos `compute` **sin** `store=True` no requieren script por el renombre en sí (son virtuales).
+   * **Modelos:** renombrar modelos **siempre** implica revisar migración (`ir.model`, `ir.model.data`, tablas relacionales, vistas, acciones…).
+
+2. **Cambiar tipos de campo**
+
+   * Se considera cambio estructural cuando **cambia la representación en la base de datos** (p.ej. `Char → Many2one`, `Selection → Many2one`, `Integer → Monetary`, `Many2one → Many2many`, etc.).
+   * Cambios “compatibles” a nivel de PostgreSQL **no suelen requerir script**, por ejemplo:
+     * `Char → Text` o ajustes de tamaño de `Char`;
+     * cambios de precisión en `Float` sin cambio de semántica.
+   * Aun así, si el cambio implica lógica nueva (p.ej. pasar de `Boolean` a `Selection` con múltiples estados) puede requerir mapeo de datos.
+
+3. **Quitar campos para reestructurar información**
+
+   * Por ejemplo, dividir un campo en varios (split) o fusionar varios en uno (merge).
+   * Siempre revisar si hay datos que deban preservarse antes de eliminar el campo original.
+
+4. **Agregar campos `compute` almacenados (`store=True`) con backfill**
+
+   * Si el campo nuevo es `compute` y `store=True`, y se espera que tenga valor para **registros históricos**, conviene:
+     * Proponer **script `post`** que haga el backfill **en lotes**.
+     * Añadir una **advertencia explícita** cuando el modelo tiene muchos registros (p.ej. millones) para que el cálculo no se haga en una sola transacción que bloquee la tabla.
+
+5. **Cambiar dominios o valores de campos `selection`**
+
+   * **Añadir nuevos valores de `selection`**:  
+     En general **no requiere migración** si solo se agregan opciones nuevas y no se tocan las existentes.
+   * **Eliminar o renombrar keys existentes de `selection`**:
+     * Puede dejar valores históricos huérfanos o inválidos → proponer script que mapee `old_value → new_value` o que normalice registros antiguos.
+     * Mencionar que hay que tener en cuenta el comportamiento de campos relacionados (p.ej. un `Many2one` con `ondelete` específico) si el `selection` influye en lógica que crea o elimina registros.
+   * **Cambios de dominio** en campos relacionales (`Many2one`, `Many2many`):
+     * Si el nuevo dominio excluye valores usados históricamente, puede ser necesario limpiar o remapear datos para que no queden registros en estados imposibles.
+     * Recordar que el `ondelete` del campo define qué ocurre al eliminar registros apuntados; hay que respetarlo al limpiar datos.
+
+6. **Cambiar o añadir `_sql_constraints` (unique / index)**
+
+   * Cambios en constraints `UNIQUE` o adición de nuevas constraints/índices pueden **fallar con datos existentes** (duplicados, valores nulos, etc.).
+   * Al menos, Copilot debe:
+     * emitir una **advertencia** sobre el riesgo de fallo en el upgrade,
+     * sugerir revisar datos previos (y, cuando se vea necesario, un **pre-script** que limpie duplicados o normalice datos antes de aplicar la constraint).
+
+7. **Cambios en `ir.model.data` / XML IDs**
+
+   * Renombres de XML IDs (`module.name → module2.name2`) o cambios en `module` / `name` suelen requerir:
+     * script para actualizar referencias dependientes (acciones, vistas, menús, records en otros módulos),
+     * o uso de utilidades de upgrade.
+   * Caso especial: registros con `no_update="1"`:
+     * Si cambia solo texto/etiquetas menores, puede no hacer falta migración.
+     * **Si cambia el contenido lógico** (ej. campo `domain`, configuración, secuencias) y el registro tiene `no_update="1"`, debes **sugerir forzar el cambio**:
+       * vía script que actualice explícitamente los registros por su `xml_id`,
+       * o mediante un proceso de “force update” apropiado.
+
+8. **Cambios de reglas de acceso / propiedad**
+
+   * Cambios profundos en `record rules` o en campos que determinan propiedad (company, website, owner…) pueden necesitar scripts para:
+     * recomputar propiedad,
+     * asignar company/website por defecto,
+     * o migrar datos entre reglas.
+
+> **Nota:** No se incluye en esta lista el caso “Añadir `required=True` a campos existentes sin default” como condición automática de migración; Copilot no debe sugerir script de migración **solo** por ese motivo, salvo que en el diff se vea claro que hay datos históricos incompatibles.
 
 ---
 
-## Scripts de migración en `migrations/`: pre / post / end (v19)
+## Cobertura de tests automatizados – reglas generales
 
-* Mismas definiciones y mapeo que en la sección de Odoo 18.
-* En Odoo 19 se pueden mencionar utilidades de `odoo.upgrade.util` (p.ej. `change_field_selection_values`, helpers para índices y constraints) cuando el diff ya usa el módulo de upgrade.([Odoo][5])
+* Cuando el diff introduzca **funcionalidad nueva no trivial** (nuevos métodos con lógica compleja, nuevos flujos de negocio, refactors grandes, nuevas APIs, etc.), revisar si existe cobertura de tests razonable para esos cambios.
+* Si no se ve una cobertura clara, sugerir de forma **concreta y breve** qué tipo de test añadir (unitarios de modelo, tests de wizards, tours, pruebas sobre reportes, etc.), sin exigir una suite completa para cada cambio.
+* Para cambios pequeños o puramente cosméticos (ajustes en textos, vistas simples, pequeñas correcciones) **no hace falta** proponer la creación de tests nuevos.
 
 ---
 
-## Convenciones de scripts en `migrations/` (v19)
+## Scripts de migración en `migrations/`: pre / post / end (reglas generales)
+
+> **Objetivo:** preservar datos y mantener instalabilidad/actualizabilidad segura.
+
+- **pre**: Se ejecutan antes de actualizar el módulo. Útiles para preparar datos o estructuras que eviten fallos durante el upgrade.
+- **post**: Se ejecutan justo después de actualizar el módulo. Ideales para recalcular datos, limpiar residuos o ajustar referencias tras el cambio.
+- **end**: Se ejecutan al final de la actualización de todos los módulos. Indicados para tareas globales que dependen de múltiples módulos o para ajustes finales.
+
+### Mapeo de cambio → acción recomendada (actualizado)
+
+* **Rename de campo almacenado (mismo modelo)**
+
+  * **Pre-script**: crear columna/alias temporal o copiar datos del campo viejo al nuevo antes de que Odoo toque el esquema, si el cambio puede romper constraints.
+  * **Post-script**: limpieza de residuos, recomputes de campos derivados si aplica.
 
-Iguales que en 18:
+* **Renombrar modelo**
 
-* Scripts idempotentes, por lotes, con logs claros.
-* Carpeta `migrations/<module_version>/` alineada con la versión del manifest.
-* `pre_*.py`, `post_*.py` y/o scripts `end` según corresponda.
+  * **Pre-script**: preparar mapeos en `ir.model` y `ir.model.data`, y ajustar referencias técnicas si es necesario.
+  * **Post-script**: re-enlazar vistas, acciones, menús, reglas y volver a chequear accesos.
+
+* **Eliminar campo y mover datos a otros campos (split/merge)**
+
+  * **Pre-script**: copiar datos a los nuevos campos (cuando sea posible) antes de que el schema elimine la columna original.
+  * **Post-script**: normalizar referencias, recalcular computes, limpiar helpers.
+
+* **Agregar campo `compute` con `store=True`**
+
+  * **Pre-script (opcional y solo en modelos muy grandes)**: crear columna en DB o preparar estructura para evitar locks largos.
+  * **Post-script (recomendado)**: backfill **en lotes** para poblar el valor almacenado; es importante para modelos con muchos registros.
+
+* **Cambiar tipo de campo con cambio real de representación**
+
+  * **Pre-script**: crear columna temporal con el nuevo tipo y migrar datos (con conversión).
+  * **Post-script**: intercambiar/renombrar columnas, borrar la vieja, disparar recomputes si hace falta.
+
+* **Cambios en `selection` (eliminar/renombrar keys existentes)**
+
+  * **Pre-script**: mapear valores antiguos → nuevos (tabla de mapeo) usando helpers como `change_field_selection_values()` cuando aplique.
+  * **Post-script**: validar que no quedan valores huérfanos y que las reglas de negocio siguen cumpliéndose.
+  * **Añadir keys nuevas**: **no proponer script** salvo que el diff muestre una migración masiva explícita de valores.
+
+* **Nuevas constraints `_sql_constraints` (unique) / índices**
+
+  * **Pre-script (recomendado cuando haya riesgo)**: detectar y resolver duplicados o datos inconsistentes antes de crear la constraint.
+  * **Post-script**: crear el índice/constraint y, si procede, validar que no haya fallos.
+
+* **Cambios en registros XML con `no_update="1"`**
+
+  * **Post-script**: actualizar esos registros por API (respetando `xml_id`) cuando el contenido lógico haya cambiado y no vaya a ser reaplicado por el upgrade normal.
+
+* **Cambios de reglas de acceso / multi-company / multi-website**
+
+  * **Pre- o post-script** según el caso, para rellenar campos obligatorios (company, website, owner) y evitar que registros queden inaccesibles.
+
+> **Regla general:** si el cambio puede **romper durante el upgrade**, usa **pre-script**; si requiere **recalcular o reaplicar** después del código nuevo, usa **post-script**. Si se necesita una acción global al final, usa **end-script**.
 
 ---
 
-## Checklist rápida para el review (v19)
+## Convenciones de scripts en `migrations/` (generales)
+
+* Ubicación: `migrations/<module_version>/`.
+* Nombres sugeridos:
+
+  * `pre_<breve-descripcion>.py`
+  * `post_<breve-descripcion>.py`
+* Requisitos:
+
+  * Idempotentes (seguros si se ejecutan más de una vez).
+  * En lotes (`batch_size` razonable) para datasets grandes.
+  * Logs claros (uso de `_logger.info`).
+  * Manejo de transacciones cuando aplique (evitar locks largos).
+  * Documentar al inicio **qué suponen** y **qué garantizan**.
+
+---
+
+## Checklist rápida para el review
 
 | Categoría          | Qué comprobar Copilot                                                                                        |
 | ------------------ | ------------------------------------------------------------------------------------------------------------ |
@@ -159,7 +287,7 @@ Iguales que en 18:
 
 ---
 
-## Heurística práctica para el bump de versión (v19)
+## Heurística práctica para el bump de versión
 
 * **SI** el diff toca cualquiera de: `models/`, `views/`, `data/`, `report/`, `security/`, `wizards/`
   **Y** `__manifest__.py` no cambia `version` → **Sugerir bump**.
@@ -168,9 +296,10 @@ Iguales que en 18:
 
 ---
 
-## Estilo del feedback (v19)
+## Estilo del feedback
 
 * El feedback debe ser **breve, concreto y accionable**.
+* Priorizar comentarios en forma de **lista corta de puntos** (3–7 ítems) y frases breves en lugar de bloques de texto extensos.
 * Ejemplos rápidos:
 
   * “La constraint nueva podría definirse como `models.Constraint` en lugar de `_sql_constraints`.”
@@ -179,17 +308,14 @@ Iguales que en 18:
 
 ---
 
-## Resumen operativo para Copilot (v19)
-
-1. **Aplicar las mismas reglas generales** que en v18 para revisión de código, manifest y migraciones.
-2. **Diferenciar claramente**:
+## Resumen operativo para Copilot
 
-   * cambios estructurales que requieren migración (según la lista ajustada),
-   * de ajustes menores que no la necesitan (p.ej. `Char → Text`, añadir valores de `selection`).
-3. Tener en cuenta las **novedades de Odoo 19**:
+1. **Detecta cambios en modelos/vistas/seguridad/datos → exige bump de `version` en `__manifest__.py`.**
+2. **Si hay cambio estructural (según la lista actualizada) → propone y describe script(s) de migración en `migrations/` (pre/post/end)**, con enfoque idempotente y en lotes.
+3. Distingue entre:
 
-   * preferir la nueva API de constraints/índices cuando corresponda,
-   * revisar cuidadosamente vistas y permisos ligados a IA, Equity, ESG, WhatsApp, VOIP, etc.
-4. Mantener un feedback **conciso y orientado a acción**, evitando micro-comentarios.
+   * **cuestiones generales**,
+   * y **matices específicos de Odoo 19**, por ej. preferir la nueva API de constraints/índices cuando corresponda.
+4. Mantén el feedback **concreto, breve y accionable**.
 
 [^odoo19]: Resumen basado en las Odoo 19 Release Notes oficiales y artículos técnicos sobre cambios del ORM e índice/constraints en Odoo 19.