diff --git a/GEMINI.md b/GEMINI.md new file mode 100644 index 0000000..0942cbd --- /dev/null +++ b/GEMINI.md @@ -0,0 +1,15 @@ +# Instrucciones para el uso de `tea` CLI + +Este proyecto utiliza `tea` para interactuar con el repositorio de Gitea. + +## Crear un Issue (Modo no Interactivo) + +Para crear un nuevo issue de forma no interactiva, se utiliza el siguiente comando, proporcionando todos los datos necesarios mediante flags: + +```bash +tea issue create --title "Título del Issue" --description "Descripción detallada del issue." --labels "etiqueta1,etiqueta2" +``` + +- `--title`: Especifica el título del issue. +- `--description`: Especifica la descripción o cuerpo del issue. +- `--labels`: Especifica una o más etiquetas separadas por comas. \ No newline at end of file diff --git a/create_issues.sh b/create_issues.sh new file mode 100644 index 0000000..7d23ae9 --- /dev/null +++ b/create_issues.sh @@ -0,0 +1,151 @@ +#!/bin/bash + +# Script para crear issues en Gitea usando tea +# Asegúrate de que tea esté logueado y configurado para el repositorio correcto. + +# Issue 1: [Core] Configuración y Modelos Base del Módulo +tea issue create --title "[Core] Configuración y Modelos Base del Módulo" --labels "feature" --description "$(cat <<'EOT' +- Crear el módulo Odoo `lims_management` con su estructura de directorios (`models`, `views`, `security`, `report`, `data`). +- Definir los grupos de seguridad principales en `security/lims_security.xml`: Recepcionista (`group_lims_receptionist`), Técnico de Laboratorio (`group_lims_technician`), y Administrador de Laboratorio (`group_lims_admin`). +- Asignar jerarquías a los grupos (ej. Administrador hereda permisos de Técnico y Recepcionista). +- Crear el menú principal del módulo "Laboratorio" y los submenús iniciales (Órdenes, Pacientes, Catálogo de Pruebas, etc.). +EOT +)" + +# Issue 2: [Core] Gestión de Pacientes y Médicos (Extensión de Contactos) +tea issue create --title "[Core] Gestión de Pacientes y Médicos (Extensión de Contactos)" --labels "feature" --description "$(cat <<'EOT' +- Extender el modelo `res.partner` para añadir los campos necesarios: + - `is_patient` (Booleano) para identificar pacientes. + - `is_doctor` (Booleano) para identificar médicos remitentes. + - `patient_history_id` (Char) para el número de historia clínica. + - `birthdate_date` (Fecha) y `gender` (Selección) para cálculos de rangos de referencia. + - `parent_id` (Many2one a `res.partner`) para asociar pacientes menores de edad con su tutor legal. +- Modificar la vista de formulario de Contactos para mostrar estos campos en una nueva pestaña "Información Clínica". +- Aplicar reglas de registro para que la información clínica sensible solo sea visible para roles autorizados del laboratorio. +EOT +)" + +# Issue 3: [Core] Catálogo de Análisis Clínicos (Extensión de Productos) +tea issue create --title "[Core] Catálogo de Análisis Clínicos (Extensión de Productos)" --labels "feature" --description "$(cat <<'EOT' +- Extender el modelo `product.template` para añadir un campo `is_lab_test` (Booleano) que identifique los productos que son análisis de laboratorio. +- Crear el modelo `lims.test.parameter` con los campos: + - `name` (Nombre del parámetro, ej. "Hemoglobina"). + - `product_id` (Many2one a `product.template`, el análisis al que pertenece). + - `uom_id` (Many2one a `uom.uom`, unidad de medida). + - `reference_min`, `reference_max` (Float, para rangos numéricos). + - `reference_text` (Char, para valores cualitativos como "Negativo"). + - `gender`, `age_min`, `age_max` para definir rangos contextuales. +- Crear la vista de producto para que en la pestaña "Laboratorio" se puedan gestionar los parámetros (`One2many` a `lims.test.parameter`). +EOT +)" + +# Issue 4: [Core] Gestión de Órdenes de Laboratorio (Sobre `sale.order`) +tea issue create --title "[Core] Gestión de Órdenes de Laboratorio (Sobre sale.order)" --labels "feature" --description "$(cat <<'EOT' +- Personalizar la vista de formulario de `sale.order` para que funcione como "Orden de Laboratorio". Cambiar etiquetas y ocultar campos no relevantes para el flujo LIMS. +- Añadir un campo `patient_id` (Many2one a `res.partner`, dominio `[('is_patient', '=', True)]`) a `sale.order`. +- Implementar un `onchange` para que al seleccionar un paciente menor de edad, el campo de dirección de factura (`partner_invoice_id`) se popule automáticamente con el tutor (`parent_id`). +- Sobrescribir el método `action_confirm` de `sale.order` para que, además de confirmar la venta, dispare la creación de los registros `lims.test` y las muestras (`stock.lot`) correspondientes. +EOT +)" + +# Issue 5: [Core] Gestión de Muestras (Sobre `stock.lot`) +tea issue create --title "[Core] Gestión de Muestras (Sobre stock.lot)" --labels "feature" --description "$(cat <<'EOT' +- Crear un producto genérico "Muestra de Laboratorio" (`product.template`) de tipo almacenable, no vendible/comprable, y con seguimiento por Lote/Nº de Serie. +- Extender el modelo `stock.lot` para añadir campos específicos de la muestra: + - `sample_state` (Selección: `pending`, `collected`, `in_analysis`, `result_ready`, `validated`, `disposed`). + - `collection_datetime` (Datetime, fecha y hora de toma). + - `collected_by_id` (Many2one a `res.users`, técnico que tomó la muestra). + - `disposal_date` (Date, fecha de descarte). + - `sale_order_id` (Many2one a `sale.order`). +- Crear ubicaciones de inventario específicas para el laboratorio (ej. "LAB/Muestras/Recepción", "LAB/Muestras/Almacenamiento Frío") separadas del stock general. +- Al confirmar una orden, generar un `stock.lot` por cada muestra requerida, asignando al paciente como propietario (`owner_id`) para que no afecte la valoración de inventario. +- Desarrollar una vista Kanban para `stock.lot` que muestre las muestras agrupadas por su estado (`sample_state`). +EOT +)" + +# Issue 6: [Core] Gestión de Pruebas y Resultados +tea issue create --title "[Core] Gestión de Pruebas y Resultados" --labels "feature" --description "$(cat <<'EOT' +- Crear el modelo `lims.test` para representar la ejecución de un análisis: + - `sale_order_line_id` (Many2one a `sale.order.line`). + - `patient_id` y `product_id` (relacionados desde la línea de pedido). + - `sample_id` (Many2one a `stock.lot`). + - `state` (Selección: `draft`, `in_process`, `result_entered`, `validated`, `cancelled`). + - `validator_id` (Many2one a `res.users`), `validation_date` (Datetime). +- Crear el modelo `lims.result` para almacenar cada valor de resultado: + - `test_id` (Many2one a `lims.test`). + - `parameter_id` (Many2one a `lims.test.parameter`). + - `value_numeric` (Float), `value_text` (Char), `value_selection` (Selección). + - `is_out_of_range` (Booleano, calculado). + - `notes` (Texto para comentarios del técnico). +- Desarrollar la interfaz de ingreso de resultados: una vista de formulario para `lims.test` con una lista editable (`One2many`) de sus `lims.result`, donde los campos de parámetro se cargan dinámicamente. +- Implementar la lógica visual para resaltar en rojo los resultados (`lims.result`) que estén fuera de su rango de referencia. +EOT +)" + +# Issue 7: [Core] Flujo de Validación y Seguridad +tea issue create --title "[Core] Flujo de Validación y Seguridad" --labels "feature" --description "$(cat <<'EOT' +- Implementar la máquina de estados en el modelo `lims.test` para controlar las transiciones (ej. no se puede validar si no hay resultados ingresados). +- Crear reglas de registro (`ir.rule`) para asegurar que: + - Los recepcionistas solo puedan crear y ver órdenes, pero no ingresar ni validar resultados. + - Los técnicos puedan ver órdenes asignadas, registrar la toma de muestra e ingresar resultados, pero no validar. + - Los administradores sean los únicos que puedan mover una prueba al estado `validated`. +- Registrar en el chatter de `lims.test` y `stock.lot` cada cambio de estado, validación o acción relevante para auditoría. +EOT +)" + +# Issue 8: [Reporte] Etiquetas de Muestras con Código de Barras +tea issue create --title "[Reporte] Etiquetas de Muestras con Código de Barras" --labels "feature" --description "$(cat <<'EOT' +- Crear una plantilla de reporte QWeb para generar etiquetas de muestra. +- La etiqueta debe incluir: Nombre del paciente, ID de la orden, tipo de muestra y un código de barras/QR único (basado en el `name` del `stock.lot`). +- Añadir un botón "Imprimir Etiquetas" en la orden de laboratorio (`sale.order`) que ejecute este reporte para todas las muestras asociadas. +EOT +)" + +# Issue 9: [Reporte] Informe Final de Resultados en PDF +tea issue create --title "[Reporte] Informe Final de Resultados en PDF" --labels "feature" --description "$(cat <<'EOT' +- Crear una plantilla de reporte QWeb compleja y profesional para el informe de resultados. +- El reporte debe tener un encabezado con datos del laboratorio (logo, dirección) y del paciente. +- La sección de resultados debe agrupar los análisis y listar los parámetros en una tabla con columnas: `Parámetro`, `Resultado`, `Unidad`, `Valor de Referencia`. +- Implementar la lógica para resaltar visualmente (ej. con color o un símbolo) los valores fuera de rango. +- Incluir una sección para comentarios/observaciones y los datos del profesional que validó el informe. +- Añadir un botón "Imprimir Informe de Resultados" en la orden, que solo se active cuando todas las pruebas estén en estado `validated`. +- El PDF generado debe guardarse automáticamente como adjunto en la orden de laboratorio. +EOT +)" + +# Issue 10: [Integración] Flujo de Facturación y Cobro +tea issue create --title "[Integración] Flujo de Facturación y Cobro" --labels "feature" --description "$(cat <<'EOT' +- Configurar las políticas de facturación en los productos de análisis (ej. `service_policy` en Odoo). +- Asegurar que la creación de la factura desde la `sale.order` funcione correctamente según la política definida (al confirmar la orden o al finalizar el servicio). +- Personalizar la vista de la factura (`account.move`) si es necesario para incluir referencias a la orden de laboratorio. +- Garantizar que los pagos se puedan registrar usando los métodos estándar de Odoo (diarios de caja, banco, etc.). +EOT +)" + +# Issue 11: [Extensión Opcional] Gestión de Inventario de Reactivos +tea issue create --title "[Extensión Opcional] Gestión de Inventario de Reactivos" --labels "feature" --description "$(cat <<'EOT' +- Configurar los reactivos como productos almacenables con seguimiento por Lote y reglas de caducidad (FEFO). +- Permitir asociar una Lista de Materiales (BOM) a cada producto de análisis para definir los reactivos que consume. +- Desarrollar la lógica para que al iniciar un `lims.test` (`state` = `in_process`), se genere y valide automáticamente un movimiento de stock (`stock.move`) para descontar los reactivos de la BOM del inventario. +- Crear alertas o notificaciones para lotes de reactivos próximos a caducar o con bajo stock (utilizando los schedulers y reglas de reorden de Odoo). +EOT +)" + +# Issue 12: [Extensión Opcional] Portal Web para Pacientes/Médicos +tea issue create --title "[Extensión Opcional] Portal Web para Pacientes/Médicos" --labels "feature" --description "$(cat <<'EOT' +- Extender los controladores del portal de Odoo para mostrar las órdenes de laboratorio (`sale.order`) al usuario logueado. +- Crear una vista en el portal para que el paciente/médico pueda ver el estado de su orden y descargar el informe PDF de resultados cuando esté disponible. +- (Avanzado) Crear un formulario en el portal para que médicos remitentes puedan crear nuevas órdenes de laboratorio de forma remota. +EOT +)" + +# Issue 13: [Extensión Opcional] Integración con Calendario para Citas +tea issue create --title "[Extensión Opcional] Integración con Calendario para Citas" --labels "feature" --description "$(cat <<'EOT' +- Integrar con el módulo `calendar` de Odoo. +- Añadir un botón en la orden de laboratorio para "Agendar Cita" de toma de muestra, creando un `calendar.event`. +- El evento del calendario debe estar vinculado al paciente y a la orden de laboratorio. +- Configurar recordatorios automáticos por email para las citas agendadas. +EOT +)" + +echo "Todos los issues han sido preparados en el script create_issues.sh" diff --git a/developmentTasks.md b/developmentTasks.md new file mode 100644 index 0000000..6e4abd7 --- /dev/null +++ b/developmentTasks.md @@ -0,0 +1,138 @@ +# Listado de Tareas de Desarrollo para Módulo LIMS en Odoo 18 + +A continuación se presenta un listado detallado y granular de las tareas de desarrollo necesarias para implementar el módulo de Gestión de Laboratorio Clínico (LIMS) sobre Odoo 18, basado en los documentos de requerimientos y diseño técnico. + +--- + +## Funcionalidades Core + +### [Core] Configuración y Modelos Base del Módulo +**Detalle:** +- Crear el módulo Odoo `lims_management` con su estructura de directorios (`models`, `views`, `security`, `report`, `data`). +- Definir los grupos de seguridad principales en `security/lims_security.xml`: Recepcionista (`group_lims_receptionist`), Técnico de Laboratorio (`group_lims_technician`), y Administrador de Laboratorio (`group_lims_admin`). +- Asignar jerarquías a los grupos (ej. Administrador hereda permisos de Técnico y Recepcionista). +- Crear el menú principal del módulo "Laboratorio" y los submenús iniciales (Órdenes, Pacientes, Catálogo de Pruebas, etc.). + +### [Core] Gestión de Pacientes y Médicos (Extensión de Contactos) +**Detalle:** +- Extender el modelo `res.partner` para añadir los campos necesarios: + - `is_patient` (Booleano) para identificar pacientes. + - `is_doctor` (Booleano) para identificar médicos remitentes. + - `patient_history_id` (Char) para el número de historia clínica. + - `birthdate_date` (Fecha) y `gender` (Selección) para cálculos de rangos de referencia. + - `parent_id` (Many2one a `res.partner`) para asociar pacientes menores de edad con su tutor legal. +- Modificar la vista de formulario de Contactos para mostrar estos campos en una nueva pestaña "Información Clínica". +- Aplicar reglas de registro para que la información clínica sensible solo sea visible para roles autorizados del laboratorio. + +### [Core] Catálogo de Análisis Clínicos (Extensión de Productos) +**Detalle:** +- Extender el modelo `product.template` para añadir un campo `is_lab_test` (Booleano) que identifique los productos que son análisis de laboratorio. +- Crear el modelo `lims.test.parameter` con los campos: + - `name` (Nombre del parámetro, ej. "Hemoglobina"). + - `product_id` (Many2one a `product.template`, el análisis al que pertenece). + - `uom_id` (Many2one a `uom.uom`, unidad de medida). + - `reference_min`, `reference_max` (Float, para rangos numéricos). + - `reference_text` (Char, para valores cualitativos como "Negativo"). + - `gender`, `age_min`, `age_max` para definir rangos contextuales. +- Crear la vista de producto para que en la pestaña "Laboratorio" se puedan gestionar los parámetros (`One2many` a `lims.test.parameter`). + +### [Core] Gestión de Órdenes de Laboratorio (Sobre `sale.order`) +**Detalle:** +- Personalizar la vista de formulario de `sale.order` para que funcione como "Orden de Laboratorio". Cambiar etiquetas y ocultar campos no relevantes para el flujo LIMS. +- Añadir un campo `patient_id` (Many2one a `res.partner`, dominio `[('is_patient', '=', True)]`) a `sale.order`. +- Implementar un `onchange` para que al seleccionar un paciente menor de edad, el campo de dirección de factura (`partner_invoice_id`) se popule automáticamente con el tutor (`parent_id`). +- Sobrescribir el método `action_confirm` de `sale.order` para que, además de confirmar la venta, dispare la creación de los registros `lims.test` y las muestras (`stock.lot`) correspondientes. + +### [Core] Gestión de Muestras (Sobre `stock.lot`) +**Detalle:** +- Crear un producto genérico "Muestra de Laboratorio" (`product.template`) de tipo almacenable, no vendible/comprable, y con seguimiento por Lote/Nº de Serie. +- Extender el modelo `stock.lot` para añadir campos específicos de la muestra: + - `sample_state` (Selección: `pending`, `collected`, `in_analysis`, `result_ready`, `validated`, `disposed`). + - `collection_datetime` (Datetime, fecha y hora de toma). + - `collected_by_id` (Many2one a `res.users`, técnico que tomó la muestra). + - `disposal_date` (Date, fecha de descarte). + - `sale_order_id` (Many2one a `sale.order`). +- Crear ubicaciones de inventario específicas para el laboratorio (ej. "LAB/Muestras/Recepción", "LAB/Muestras/Almacenamiento Frío") separadas del stock general. +- Al confirmar una orden, generar un `stock.lot` por cada muestra requerida, asignando al paciente como propietario (`owner_id`) para que no afecte la valoración de inventario. +- Desarrollar una vista Kanban para `stock.lot` que muestre las muestras agrupadas por su estado (`sample_state`). + +### [Core] Gestión de Pruebas y Resultados +**Detalle:** +- Crear el modelo `lims.test` para representar la ejecución de un análisis: + - `sale_order_line_id` (Many2one a `sale.order.line`). + - `patient_id` y `product_id` (relacionados desde la línea de pedido). + - `sample_id` (Many2one a `stock.lot`). + - `state` (Selección: `draft`, `in_process`, `result_entered`, `validated`, `cancelled`). + - `validator_id` (Many2one a `res.users`), `validation_date` (Datetime). +- Crear el modelo `lims.result` para almacenar cada valor de resultado: + - `test_id` (Many2one a `lims.test`). + - `parameter_id` (Many2one a `lims.test.parameter`). + - `value_numeric` (Float), `value_text` (Char), `value_selection` (Selección). + - `is_out_of_range` (Booleano, calculado). + - `notes` (Texto para comentarios del técnico). +- Desarrollar la interfaz de ingreso de resultados: una vista de formulario para `lims.test` con una lista editable (`One2many`) de sus `lims.result`, donde los campos de parámetro se cargan dinámicamente. +- Implementar la lógica visual para resaltar en rojo los resultados (`lims.result`) que estén fuera de su rango de referencia. + +### [Core] Flujo de Validación y Seguridad +**Detalle:** +- Implementar la máquina de estados en el modelo `lims.test` para controlar las transiciones (ej. no se puede validar si no hay resultados ingresados). +- Crear reglas de registro (`ir.rule`) para asegurar que: + - Los recepcionistas solo puedan crear y ver órdenes, pero no ingresar ni validar resultados. + - Los técnicos puedan ver órdenes asignadas, registrar la toma de muestra e ingresar resultados, pero no validar. + - Los administradores sean los únicos que puedan mover una prueba al estado `validated`. +- Registrar en el chatter de `lims.test` y `stock.lot` cada cambio de estado, validación o acción relevante para auditoría. + +--- + +## Tareas de Reportes + +### [Reporte] Etiquetas de Muestras con Código de Barras +**Detalle:** +- Crear una plantilla de reporte QWeb para generar etiquetas de muestra. +- La etiqueta debe incluir: Nombre del paciente, ID de la orden, tipo de muestra y un código de barras/QR único (basado en el `name` del `stock.lot`). +- Añadir un botón "Imprimir Etiquetas" en la orden de laboratorio (`sale.order`) que ejecute este reporte para todas las muestras asociadas. + +### [Reporte] Informe Final de Resultados en PDF +**Detalle:** +- Crear una plantilla de reporte QWeb compleja y profesional para el informe de resultados. +- El reporte debe tener un encabezado con datos del laboratorio (logo, dirección) y del paciente. +- La sección de resultados debe agrupar los análisis y listar los parámetros en una tabla con columnas: `Parámetro`, `Resultado`, `Unidad`, `Valor de Referencia`. +- Implementar la lógica para resaltar visualmente (ej. con color o un símbolo) los valores fuera de rango. +- Incluir una sección para comentarios/observaciones y los datos del profesional que validó el informe. +- Añadir un botón "Imprimir Informe de Resultados" en la orden, que solo se active cuando todas las pruebas estén en estado `validated`. +- El PDF generado debe guardarse automáticamente como adjunto en la orden de laboratorio. + +--- + +## Tareas de Integración (Obligatorias) + +### [Integración] Flujo de Facturación y Cobro +**Detalle:** +- Configurar las políticas de facturación en los productos de análisis (ej. `service_policy` en Odoo). +- Asegurar que la creación de la factura desde la `sale.order` funcione correctamente según la política definida (al confirmar la orden o al finalizar el servicio). +- Personalizar la vista de la factura (`account.move`) si es necesario para incluir referencias a la orden de laboratorio. +- Garantizar que los pagos se puedan registrar usando los métodos estándar de Odoo (diarios de caja, banco, etc.). + +--- + +## Tareas de Extensiones Opcionales + +### [Extensión Opcional] Gestión de Inventario de Reactivos +**Detalle:** +- Configurar los reactivos como productos almacenables con seguimiento por Lote y reglas de caducidad (FEFO). +- Permitir asociar una Lista de Materiales (BOM) a cada producto de análisis para definir los reactivos que consume. +- Desarrollar la lógica para que al iniciar un `lims.test` (`state` = `in_process`), se genere y valide automáticamente un movimiento de stock (`stock.move`) para descontar los reactivos de la BOM del inventario. +- Crear alertas o notificaciones para lotes de reactivos próximos a caducar o con bajo stock (utilizando los schedulers y reglas de reorden de Odoo). + +### [Extensión Opcional] Portal Web para Pacientes/Médicos +**Detalle:** +- Extender los controladores del portal de Odoo para mostrar las órdenes de laboratorio (`sale.order`) al usuario logueado. +- Crear una vista en el portal para que el paciente/médico pueda ver el estado de su orden y descargar el informe PDF de resultados cuando esté disponible. +- (Avanzado) Crear un formulario en el portal para que médicos remitentes puedan crear nuevas órdenes de laboratorio de forma remota. + +### [Extensión Opcional] Integración con Calendario para Citas +**Detalle:** +- Integrar con el módulo `calendar` de Odoo. +- Añadir un botón en la orden de laboratorio para "Agendar Cita" de toma de muestra, creando un `calendar.event`. +- El evento del calendario debe estar vinculado al paciente y a la orden de laboratorio. +- Configurar recordatorios automáticos por email para las citas agendadas.