![[FIX] l10n_ec_edi_common: Agregar Permisos para Bypass contable](/web/image/blog.post/95/author_avatar/%5BFIX%5D%20l10n_ec_edi_common:%20Agregar%20Permisos%20para%20Bypass%20contable?unique=d845a6a)
- Riesgo: bajo
- Tipo: nueva funcionalidad
- Descripción:
- Agregamos permiso exclusivo para mostrar el bypass de validaciones en facturas
- Check nuevo en la seccion de Extra Rights (visible en vista usuario con modo debug activado)
- Requerido minimo tener los permisos básicos de contabilidad
- Odoobot y Administrador viene con el permiso activado
- Agregamos no_open en los campos de tipo de identificacion para que no editen ningun dato en su vista Form
- Número Ticket: #40543 40040
Detalles (Obligatorio)
Propósito de la sección:
Explicar de manera clara y comprensible qué se hizo y por qué, desde el punto de vista del usuario o del negocio.
Qué debe contener:
- 1 o 2 párrafos cortos (no bullets).
- Lenguaje no técnico o mínimamente técnico.
- Enfocado en el problema que existía y la mejora introducida.
- Si aplica, mencionar el área/módulo donde se encuentra el cambio (sin usar nombres internos de módulos).
- Debe contener por lo menos una imagen.
Guía para redactar (estructura sugerida):
- Situación previa (breve):
- “Antes, los usuarios experimentaban…”
- Qué se hizo (resumen del cambio):
- “Se mejoró / corrigió / ajustó…”
- Resultado esperado (beneficio general):
- “Esto permite…”, “Con esto se logra…”.
¿Qué cambia? (Obligatorio)
Propósito de la sección:
Desglosar de forma clara y accionable los cambios más relevantes en formato de lista.
Qué debe contener:
- Entre 1 y 5 bullets como máximo.
- Cada punto debe iniciar con un verbo en pasado:
- “Se mejoró…”, “Se corrigió…”, “Se optimizó…”, “Se agregó…”, “Se ajustó…”
- Enfocado en cambios visibles o relevantes para el usuario.
Guía para redactar:
Cada bullet debe responder a una de estas preguntas:
- ¿Qué ahora funciona mejor?
- ¿Qué error se corrigió?
- ¿Qué nueva capacidad tiene el usuario?
Detalle técnico (Opcional)
Propósito de la sección:
Documentar cambios internos relevantes que no son necesarios para todos los usuarios, pero sí útiles para soporte, auditoría o desarrollo.
Usar cuando:
- Hay cambios de librerías, arquitectura o lógica interna.
- El cambio puede ser relevante para troubleshooting futuro.
- Se requiere trazabilidad técnica.
Qué debe contener:
- 1 a 3 bullets como máximo.
- Lenguaje técnico aceptable.
- Evitar detalles excesivamente bajos (logs, funciones internas específicas).
[FIX] l10n_ec_edi_common: Agregar Permisos para Bypass contable