Arquitectura de módulos

Un módulo es un paquete Python con tryton.cfg, registro en el Pool, modelos y, cuando aplica, XML, vistas, traducciones, informes y pruebas.

Objetivos de aprendizaje

• Declare dependencias mínimas y extras_depend para integraciones opcionales. Al terminar, compruebe el resultado con un registro de prueba y documente quién es responsable.
• Extienda modelos con PoolMeta y llame siempre a super(). Al terminar, compruebe el resultado con un registro de prueba y documente quién es responsable.
• Reutilice modelos, vistas y workflows del core. Al terminar, compruebe el resultado con un registro de prueba y documente quién es responsable.
• Use mensajes traducibles y reglas de acceso explícitas. Al terminar, compruebe el resultado con un registro de prueba y documente quién es responsable.
• Trate migraciones y compatibilidad como parte del diseño. Al terminar, compruebe el resultado con un registro de prueba y documente quién es responsable.

Conceptos que debe dominar

• Declare dependencias mínimas y extras_depend para integraciones opcionales.
• Extienda modelos con PoolMeta y llame siempre a super().
• Reutilice modelos, vistas y workflows del core.
• Use mensajes traducibles y reglas de acceso explícitas.
• Trate migraciones y compatibilidad como parte del diseño.

Práctica guiada

1. Actividad 1. Declare dependencias mínimas y extras_depend para integraciones opcionales. Realícela primero en un ambiente de ensayo, registre las precondiciones y compare el resultado esperado con el obtenido.

2. Actividad 2. Extienda modelos con PoolMeta y llame siempre a super(). Realícela primero en un ambiente de ensayo, registre las precondiciones y compare el resultado esperado con el obtenido.

3. Actividad 3. Reutilice modelos, vistas y workflows del core. Realícela primero en un ambiente de ensayo, registre las precondiciones y compare el resultado esperado con el obtenido.

4. Actividad 4. Use mensajes traducibles y reglas de acceso explícitas. Realícela primero en un ambiente de ensayo, registre las precondiciones y compare el resultado esperado con el obtenido.

5. Actividad 5. Trate migraciones y compatibilidad como parte del diseño. Realícela primero en un ambiente de ensayo, registre las precondiciones y compare el resultado esperado con el obtenido.

Cómo verificar el resultado

• La compañía, usuario, idioma, zona horaria y fecha son los esperados.
• Los permisos permiten únicamente las operaciones asignadas a la responsabilidad.
• Los cambios dejan trazabilidad y los documentos relacionados conservan consistencia.
• El procedimiento puede repetirse con el mismo resultado y tiene una forma documentada de corrección.
• Una copia restaurada permite reproducir el proceso sin depender del servidor de producción.

Errores frecuentes

• Confundir guardar con confirmar, contabilizar, pagar o cerrar.
• Probar solamente con el usuario administrador y concluir que los permisos funcionan.
• Cambiar estados o totales directamente con SQL para evitar una validación.
• Actualizar módulos sin inventario, copia restaurable y conciliación posterior.
• Documentar únicamente el camino exitoso y omitir cancelaciones, correcciones y excepciones.

Perspectiva para desarrolladores

Identifique los modelos, campos, botones, dominios y reglas de acceso involucrados. Antes de extender el proceso, localice el módulo que posee la regla, revise sus pruebas y conserve sus invariantes mediante super(). Una personalización correcta debe funcionar con diferentes compañías, idiomas, permisos y estados.

Lista de control para producción

• La compañía, usuario, idioma, zona horaria y fecha son los esperados.
• Los permisos permiten únicamente las operaciones asignadas a la responsabilidad.
• Los cambios dejan trazabilidad y los documentos relacionados conservan consistencia.
• El procedimiento puede repetirse con el mismo resultado y tiene una forma documentada de corrección.
• Una copia restaurada permite reproducir el proceso sin depender del servidor de producción.