4. Helpdesk y Soporte
  • Iniciar sesión

    • 4. Helpdesk y Soporte

    helpdesk_halo_integration — Integración Helpdesk ↔ Halo ITSM
    Versión 17.0.1.0.0
    Autor ITConsulting
    Dependencias helpdesk, mail, hr_holidays
    Complejidad Muy Alta (integración API bidireccional)

    Descripción Funcional:
    Integración bidireccional entre Odoo Helpdesk y Halo ITSM via API REST con autenticación OAuth2. Sincroniza tickets, acciones (respuestas), adjuntos y notificaciones. Incluye un gestor inteligente de notificaciones que verifica vacaciones del agente antes de notificar.

    Descripción Técnica:

    Modelos:

    Modelo Tipo Descripción
    halo.api.service AbstractModel Servicio central OAuth2. Gestión de tokens, reintentos, cache de estados/outcomes (5 min)
    helpdesk.ticket Herencia Campos Halo (URL, JSON, contador adjuntos, estado cerrado). Métodos de sincronización
    helpdesk.halo.mapping Normal Mapeo bidireccional Odoo ↔ Halo: status, priority, type. Constraint unique_mapping
    helpdesk.halo.update Normal Audit trail de sincronizaciones
    helpdesk.halo.attachment Normal Adjuntos descargados desde Halo
    helpdesk.notification.manager AbstractModel Gestor inteligente de notificaciones con check de vacaciones
    res.config.settings Transient Configuración OAuth2: endpoint, client_id, secret, token, scope

    OAuth2 — Gestión de token:

    _refresh_token_if_needed()
  → _regenerate_token_with_scope_analysis()
    → Prueba: scope='all', luego 'read write', luego None
    → _verify_token_access(): GET /api/tickets para validar
  → Almacena en ir.config_parameter (encriptado)
_make_authenticated_request(): Reintento automatico en 401/403

    Sincronización de tickets:

    action_sync_halo_data()
  → _sync_halo_actions(): Crea notas en chatter desde acciones Halo
  → _sync_halo_attachments(): Descarga adjuntos desde API Halo
  → _update_basic_fields_from_halo(): Actualiza status, priority via mapeo
  → _generate_halo_summary_html(): Resumen HTML con datos Halo

    Wizard halo.action.wizard:
    - Campos: ticket_id, action_description, action_type, halo_response (HTML)
    - action_create_halo_action(): POST a /api/Tickets/{id}/Actions

    Notificación inteligente:

    check_and_notify_ticket()
  → _is_user_on_leave(): Consulta hr_holidays
  → Si de vacaciones: _send_fallback_notification() (email)
  → Si disponible: _send_discuss_notification() (canal ExtendedSupport_PPHE)
  → _send_webhook_notification(): Notificacion webhook externo

    Datos:
    - Canal Discuss: ExtendedSupport_PPHE
    - Cron: DESACTIVADO (se usa webhook externo)
    - Mapeos iniciales en halo_mapping_data.xml
    - Template de email de notificación Halo

    Configuración en Odoo (Ajustes):
    - URL endpoint Halo
    - Client ID / Client Secret
    - Botones: "Autorizar", "Comprobar conexion", "Diagnosticar permisos"

    itc_helpdesk_solution_tab — Pestana de Solución
    Versión 17.0.1.0.3
    Autor ITConsulting
    Dependencias base, helpdesk, portal

    Descripción Funcional:
    Añade una pestana "Solucion" en tickets de helpdesk donde los agentes documentan la resolución. Visible en el portal del cliente.

    Descripción Técnica:
    - helpdesk.ticket (herencia): Campo solution (Html)
    - Vista portal con solucion visible para el cliente

    itc_ticket_user — Usuario Final del Ticket
    Versión 17.0.1.0.2
    Autor ITConsulting
    Dependencias helpdesk, contacts

    Descripción Funcional:
    Añade el campo "Ticket User" al ticket de Helpdesk para identificar a la persona real que solicita el trabajo en la propiedad (hotel), distinta del cliente/empresa principal (partner_id) y del Property User (x_studio_property_user). El desplegable solo muestra contactos hijos del Property User seleccionado y permite crear un contacto nuevo al vuelo. El email del Ticket User es obligatorio: sin él no se puede guardar el ticket ni crear el contacto — es la garantía de que Extended Support siempre podrá responder al solicitante.

    Descripción Técnica:

    Modelo helpdesk.ticket (herencia):

    • ticket_user_id (Many2one → res.partner): campo principal. Dominio: [('parent_id', '=', x_studio_property_user), ('is_company', '=', False)] — solo personas hijas del Property User. Contexto: default_parent_id = x_studio_property_user, default_is_company = False, default_type = 'contact', from_ticket_user = True.
    • @api.constrains('ticket_user_id') → _check_ticket_user_email: lanza UserError si el contacto seleccionado NO tiene email. Bloquea el guardado del ticket.

    Modelo res.partner (herencia):

    • create() override: si context.get('from_ticket_user') y hay parent_id pero no email → ValidationError. Impide crear contactos hijos sin email desde el "crear al vuelo" del campo.
    • @api.constrains('email', 'parent_id') → _check_email_for_ticket_user_contacts: si el contacto es hijo de una empresa y está usado como ticket_user_id en al menos un ticket, no permite dejarlo sin email. Protege ante ediciones posteriores del contacto que romperían la comunicación con el solicitante.

    Vistas (views/helpdesk_ticket_views.xml):

    • view_helpdesk_ticket_form_ticket_user: hereda de la vista de Studio y añade el campo tras x_studio_property_user con dominio, contexto y options="{'no_quick_create': False, 'no_create_edit': False}".
    • view_helpdesk_ticket_tree_ticket_user: añade el campo (invisible por defecto, activable desde el selector de columnas) al listado de tickets.

    Fix multi-compañía (v17.0.1.0.2 — mayo 2026):

    El dominio implícito que Odoo añade a partner_id por el check_company hace referencia a la variable company_id del formulario. Cuando esta variable NO existe en la vista renderizada (Studio la había ocultado), el autocomplete del campo Cliente revienta con Name 'company_id' is not defined y hace inutilizable la creación / edición de tickets.

    El fix inyecta <field name="company_id" invisible="1"/> antes de partner_id, para que la variable esté disponible al evaluar el dominio. Y se aplica en DOS vistas core de Odoo (no en la vista Studio) para sobrevivir a cambios futuros de personalización:

    • view_helpdesk_ticket_form_company_fix → hereda helpdesk.helpdesk_ticket_view_form (form estándar del backend).
    • view_helpdesk_ticket_quick_create_company_fix → hereda helpdesk.quick_create_ticket_form (form inline del "Nuevo" desde el kanban del cajetín, que reventaba de forma independiente).

    Ruta de configuración: Servicio de atención → Tickets → cualquier ticket → campo Ticket User justo debajo de Property User.

    Cómo verificar:

    1. Abre un ticket con Property User asignado — el desplegable de Ticket User solo muestra los contactos hijos de esa propiedad.
    2. Intenta seleccionar un contacto sin email → aparece el aviso "Email Required for Ticket User" y no permite guardar.
    3. Crea un contacto al vuelo desde el mismo campo dejando el email vacío → ValidationError con el mensaje "Email Required for New Contact".
    4. Edita un contacto ya usado como Ticket User y vacía su email → bloqueo con el número de tickets en los que está siendo usado.
    5. Fix multi-compañía: haz clic en Nuevo desde el kanban de Helpdesk y en el form del ticket clica el campo Cliente → el autocomplete abre sin el error company_id is not defined.

    itc_mastel_helpdesk_pes_tech_support — Support Status (PES / Technical Support / Hotel Dashboard)
    Versión 17.0.1.18.0
    Autor ITConsulting
    Dependencias helpdesk, sale, contacts, mail
    Ticket origen #43073
    Complejidad Alta (backend + OWL frontend + sincronización bidireccional)

    Descripción Funcional:
    Da visibilidad inmediata al equipo de Soporte del Support Status contratado por cada cliente (PES OPERA, PES SIMPHONY, PES REVO, Technical Support, Hotel Dashboard…) y sus fechas de vigencia. Consta de cuatro piezas coordinadas:

    • Tabla de fechas por cliente: en la ficha del contacto (pestaña Support Status), una fila por cada tipo contratado, con Fecha Inicio / Fecha Fin y un Estado calculado (Activo / Caducado / Pendiente / Pendiente de fechas / No contratado). Editable solo por Administración y por el grupo Studio Projects; el resto la ve en solo lectura. Cada alta / cambio / baja se registra en el chatter del cliente con usuario y fecha-hora.
    • Pop-up OWL en el ticket: al ABRIR un ticket cuyo Property User tiene servicio especial contratado — o al ASIGNAR el Property User en un ticket ya abierto — se abre automáticamente un diálogo con los servicios contratados, sus fechas y estados, además de las Notas Internas del Property User. Un icono en la cabecera del ticket (junto al kanban_state) permite reabrirlo cuando se quiera.
    • Aviso automático por email a Extended Support: al crearse un ticket o al asignar el Property User, si éste tiene servicio especial contratado se envía un correo bilingüe (español + inglés) al equipo Extended Support con los datos del ticket y las Notas Internas del Property User. Con protección anti-duplicado (extended_support_notified).
    • Menú Contactos → Support Status: lista dedicada de una fila por cliente y tipo, con filtros por estado (Activo / Caducado / Pendiente / Pendiente de fechas / Con fechas) y agrupación por Tipo o Cliente. Solo lectura y exportable.

    Regla de alcance del aviso: saltan pop-up y email para TODO Support Status (PES, Technical Support, OHIP…) EXCEPTO los productos de panel/BI (Hotel Dashboard, HD - POWER BI, cualquier HD - *), que solo se muestran informativos en el pop-up.

    Regla de datos: el Support Status solo puede asignarse a contactos tipo Empresa; un constraint Python en res.partner rechaza el intento en personas físicas por ambas vías (tabla y tags).

    Descripción Técnica:

    Modelos:

    Modelo Tipo Descripción
    itc.partner.support.status Normal Fila cliente × tipo. Espejo 1:1 del campo Studio x_studio_support_status_ (tags). Constraint SQL uniq_partner_support impide duplicar el mismo tipo en el mismo cliente.
    res.partner Herencia One2many support_status_line_ids, sincronización bidireccional tabla↔tags, HTML del pop-up, constraint "solo empresas".
    helpdesk.ticket Herencia Campos calculados (partner_has_special_support, partner_show_support_popup, partner_support_popup_html), envío del aviso, flag anti-duplicado.

    Campos clave en itc.partner.support.status:

    • partner_id (Many2one → res.partner, cascade)
    • support_status_id (Many2one → x_support_status, cascade)
    • date_start, date_end (Date)
    • state (Selection calculado + buscable, NO almacenado): active / expired / pending / pending_dates / not_contracted. Sin campo almacenado ni cron: el _search_state traduce cada valor a un dominio sobre las fechas evaluado con today — siempre correcto.

    Sincronización bidireccional tabla ↔ tag (evita bucles con skip_tag_sync / skip_line_sync):

    Alta de fila  → _sync_tag_to_partner(add=True)  → añade tag al partner
Baja de fila  → si es la última de ese tipo, quita el tag del partner
Cambio de tipo → añade el nuevo tag y, si el viejo queda huérfano, lo elimina
Cambio de tags en el partner (write x_studio_support_status_)
              → _sync_support_status_lines(): crea las filas que falten y
                 borra las que sobren, para dejar 1 fila por cada tag

    Cálculo del pop-up y del email (helpdesk.ticket._compute_partner_support):

    • Fuente del Support Status: SIEMPRE x_studio_property_user. Sin fallback al partner_id ni a la Commercial Entity — si el Property User está vacío, no hay aviso.
    • partner_has_special_support (dispara el email): solo Support Status en alcance (PES / Technical). Hotel Dashboard NO cuenta aunque tenga fechas.
    • partner_show_support_popup (dispara el pop-up): Support Status en alcance O Notas Internas del Property User. Así el pop-up también sale si el hotel solo tiene notas relevantes.

    Aviso a Extended Support (_notify_extended_support):

    • Destinatario configurable vía ir.config_parameter: itc_mastel_helpdesk_pes_tech_support.extended_support_email (por defecto [email protected]).
    • Se envía como recipient_ids (creando el partner si no existe) y con email_to=False para NO duplicar la entrega.
    • email_from robusto: intenta company.email → user.email → [email protected].
    • Se dispara en create() y también en write() cuando cambia x_studio_property_user (por eso funciona al asignar el Property User más tarde). El flag extended_support_notified evita reenvíos.

    Frontend OWL (static/src/js/support_status_popup.js):

    • Widget de campo itc_support_status_popup registrado sobre un booleano (partner_show_support_popup).
    • Usa useEffect ligado a resId Y a partner_show_support_popup: el pop-up salta al entrar al ticket y al pasar el booleano de false→true por asignar el Property User (el efecto se re-ejecuta sin recargar).
    • Renderiza el partner_support_popup_html calculado en servidor dentro de un Dialog estándar (@web/core/dialog/dialog).
    • Se coloca arriba a la derecha en el form del ticket, junto al indicador de kanban_state (views/helpdesk_ticket_views.xml).

    Plantilla de email (data/mail_template.xml): plantilla bilingüe con Customer, Property User, Support Status contratados, Título del Ticket / Ticket Title, Ticket ID y Notas Internas. auto_delete=False para conservar el rastro.

    • v17.0.1.18.0 (jul 2026, #43073): se añade la línea Título del Ticket (ES) / Ticket Title (EN) con t-out="object.name", ubicada entre Support Status y Número de Ticket en ambos bloques idiomáticos, para que Extended Support vea el asunto del ticket directamente en el aviso sin necesidad de abrir Odoo.

    Menú y vistas (views/support_status_views.xml): tree, form y search con filtros por estado y agrupación por Tipo / Cliente. Menú Contactos → Support Status (sequence=20).

    Permisos: la edición de la tabla se concede en tiempo de instalación al grupo Studio Projects por nombre (no tiene xml_id) vía <function> que llama a _itc_setup_projects_access — crea el ir.model.access con xml_id propio para actualizaciones idempotentes.

    Ruta de configuración:

    • Fechas de un cliente: Contactos → ficha del hotel → pestaña Support Status.
    • Listado global: Contactos → menú Support Status.
    • Destinatario del aviso: Ajustes → Técnico → Parámetros del sistema → itc_mastel_helpdesk_pes_tech_support.extended_support_email.

    Cómo verificar:

    1. Abre la ficha de un hotel con PES contratado y ve a la pestaña Support Status: debe haber una fila por cada tag de Mastel Data. Como usuario Projects/Admin, edita una Fecha Fin y guarda → la modificación aparece en el chatter del cliente.
    2. Añade una fila nueva desde la pestaña → el tag correspondiente aparece automáticamente en el campo Studio x_studio_support_status_. Elimínala → el tag desaparece si no queda ninguna otra fila del mismo tipo.
    3. Crea un ticket nuevo cuyo Property User sea ese hotel → salta el pop-up con los servicios, sus fechas y estados. Al guardarlo, Extended Support recibe el correo bilingüe con los datos.
    4. Crea un ticket sin Property User y luego asígnalo → el pop-up salta al instante (sin recargar) y el email sale una sola vez.
    5. Menú Contactos → Support Status → filtra por "Caducado" y agrupa por Cliente para revisar renovaciones.
    6. Intenta añadir un tag de Support Status a un contacto tipo Individuo → error de validación "solo puede asignarse a contactos de tipo Empresa".
    7. Comprueba que el email recibido por Extended Support incluye la línea Título del Ticket / Ticket Title con el asunto del ticket, situada entre Support Status y Número de Ticket.

    itc_mastel_pes_weekly_report — Informe PES Semanal
    Versión 17.0.1.0.13
    Autor ITConsulting
    Dependencias helpdesk, hr_timesheet, mail
    Dependencia sistema wkhtmltopdf (invocado por subprocess)

    Descripción Funcional:
    Cron semanal (todos los lunes a las 11:00 CET / 09:00 UTC) que genera un PDF corporativo con las horas de Premium Extended Support consumidas la semana anterior y lo envía por correo al equipo Extended Support de Mastel. El informe incluye: KPIs de la semana (tickets PES, horas brutas, horas PES, Δ vs semana anterior), detalle línea a línea (fecha, ticket, cliente, agente, tipo de horas, multiplicador, horas), desglose por tipo de horas y comparativa mes a mes de los últimos tres meses con marca "parcial" cuando el mes en curso no se ha cerrado.

    Descripción Técnica:

    Modelo mastel.pes.weekly.report (AbstractModel):

    • _get_previous_week_range(today=None): devuelve (monday, sunday) de la semana anterior a today. Si ir.config_parameter pes_report.today_override (formato YYYY-MM-DD) está fijado, se usa como "hoy" — permite regenerar informes de semanas históricas para validación sin desplegar código nuevo. Borrar el parámetro vuelve al comportamiento normal.
    • _get_pes_multiplier_ids(): busca en timesheet.time.multiplier por prefijo de nombre PREMIUM CS% / PREMIUM ACS% — no hardcodea IDs.
    • _get_pes_lines(date_from, date_to): sudo() obligatorio (el cron corre como OdooBot). Dominio: timesheet_time_multiplier_id in [PES ids] AND date entre from y to. Ordenado por fecha, id.
    • _build_report_context(): calcula filas del detalle, totales de la semana, agregación por tipo de horas (consumption_agg), Δ vs semana anterior y llama a _build_monthly_comparison.
    • _build_monthly_comparison(ref_date): recorre los 3 meses hasta ref_date, marca el último como "parcial" si end < month_end, calcula tickets distintos, horas brutas, horas PES y Δ vs mes anterior.
    • _render_html(ctx): construye HTML A4 apaisado con CSS inline (colores oro #CBB473, negro corporativo). Logo Mastel embebido como data URI base64 desde static/src/img/mastel_logo.png.
    • _html_to_pdf(html): escribe HTML a fichero temporal e invoca wkhtmltopdf vía subprocess con flags de landscape A4 y márgenes 14/10/10/30mm. Timeout 60s. Devuelve bytes del PDF.
    • _cron_send_weekly_report(): entrypoint del cron. Crea ir.attachment con el PDF (nombre Informe_PES_YYYYMMDD.pdf) y envía la plantilla con subject = "Informe PES - DDMMYYYY".

    Identificador canónico de "trabajo PES": el parte de horas (account.analytic.line) tiene en su timesheet_time_multiplier_id uno de los multipliers "PREMIUM CS Extended Support Hours X 1" o "PREMIUM ACS Extended Support Hours x 1.25". El factor sale del propio registro (multiplier), la etiqueta corta se abrevia en _short_multiplier_label (ej. "PREMIUM CS (OOH)").

    Cron (data/ir_cron.xml): ir.cron Mastel — Envío semanal Informe PES. interval_number=7, interval_type=days, numbercall=-1, ejecutado como base.user_root. nextcall se fija al siguiente lunes 09:00 UTC.

    Plantilla de correo (data/mail_template.xml) mail_template_mastel_pes_weekly:

    • Modelo: res.users (se envía como el usuario que ejecuta el cron).
    • Destinatarios fijos (Sebastian Boccassi, Erika Guzmán, operations@, Aníbal Merlo, Rafael Godoy).
    • Subject sobreescrito en tiempo de envío con la fecha (ctx.pes_subject_date).
    • Cuerpo bilingüe corto; el contenido va en el PDF adjunto.

    Detalles del PDF:

    • Rótulos y meses en español (MONTH_ES, WEEKDAY_ES).
    • Formato de números es-ES con coma decimal (_fmt_num).
    • Encabezado con logo, cliente, período (formato "Semana N · D – D mes AAAA") y fecha de generación.
    • KPIs en tarjetas con borde superior oro.
    • Salto de página forzado antes de la comparativa mensual para no partir la tabla.

    Ruta de configuración:

    • Cron: Ajustes → Técnico → Automatización → Acciones planificadas → "Mastel — Envío semanal Informe PES".
    • Override histórico: Ajustes → Técnico → Parámetros del sistema → clave pes_report.today_override con valor YYYY-MM-DD.

    Cómo verificar:

    1. Ejecuta manualmente el cron desde Acciones planificadas → botón "Ejecutar manualmente". En el log del servidor debe aparecer [PES] Generando informe … → … seguido de [PES] Enviado: N líneas, X h PES.
    2. Comprueba la bandeja de entrada de los destinatarios: correo "Informe PES - DDMMAAAA" con PDF adjunto Informe_PES_AAAAMMDD.pdf.
    3. Regenera un informe histórico: crea el parámetro de sistema pes_report.today_override = 2026-04-27 (un lunes), lanza el cron manualmente → sale el informe de la semana 14 – 20 abr 2026. Borra el parámetro cuando termines.
    4. Verifica el filtro de líneas: cualquier account.analytic.line cuyo timesheet_time_multiplier_id no sea PREMIUM CS/ACS queda fuera; renombrar el multiplier rompe el informe (aparecerá "sin actividad PES").
    5. Revisa la comparativa mensual: el mes en curso debe mostrarse como "(parcial, N semana(s))".

    itc_development_request — Portal de Solicitudes de Desarrollo
    Versión 17.0.1.0.0
    Autor IT Consulting
    Dependencias helpdesk, website

    Descripción Funcional:
    Formulario web interno (/development-request) para que empleados de Mastel creen tickets de desarrollo HD/OHIP sin acceso al backend de Odoo.

    Descripción Técnica:

    Rutas del controller:

    Ruta Método Descripción
    /development-request GET, auth=user Muestra formulario (solo usuarios internos)
    /development-request/submit POST, csrf Valida, crea ticket, envia email, redirige
    /development-request/submitted GET Página de confirmacion

    Creación del ticket:

    team_id = "15. DEVELOPMENTS"
ticket_type_id = "Development Request"
x_studio_property_user = customer_id (cliente hotel)

    Email: Tabla HTML con detalles del ticket → integrationsteam, hdteam, info

    itc_helpdesk_partner_warning — Avisos de Partner

    Descripción Funcional: Muestra los avisos de venta del partner al seleccionar cliente en un ticket. helpdesk.ticket (herencia con onchange en partner_id).

    itc_github_link — Enlace GitHub para Helpdesk y Project

    Propósito: Añade un campo URL (github_url) en tickets de Helpdesk y tareas de Project para vincular directamente a repositorios, PRs, issues o branches de GitHub.

    Origen: ITC Custom (LGPL-3)

    Dependencias: helpdesk, project

    Lo que añade:

    • Campo github_url (Char, widget URL) en helpdesk.ticket — columna derecha, después de Estimated Time
    • Campo github_url (Char, widget URL) en project.task — después de Fecha límite
    • Campo opcional, clickeable (abre en nueva pestaña)

    Campos clave:

    Campo Modelo Tipo Widget
    github_url helpdesk.ticket Char url
    github_url project.task Char url

    Notas técnicas:

    • Vistas heredan de base Odoo (no Studio) con priority=990
    • Helpdesk: hereda helpdesk.helpdesk_ticket_view_form — xpath a group[2] position=inside
    • Project: hereda project.view_task_form2 — xpath a date_deadline position=after

    Cómo verificar:

    1. Abrir ticket en Helpdesk → campo "GitHub Link" en columna derecha
    2. Abrir tarea en Project → campo "GitHub Link" después de Fecha límite
    3. Introducir URL → se renderiza como enlace clickeable
    4. Dejar vacío → sin error (campo opcional)

    helpdesk_halo_integration — ver arriba (detallado)

    bi_website_ticket_problem_solution_ent — FAQ de Tickets (BrowseInfo Enterprise)

    Descripción Funcional: Sistema FAQ/Q&A para tickets. Modelo solution.ticket, reporte PDF de soluciones, vista web.

    helpdesk_counting — Conteo de Tickets

    Descripción Funcional: Añade contadores y metricas de tickets de helpdesk. Herencia de helpdesk.ticket (Kanak Infosystems).

    helpdesk_timesheet_customization — Hoja de Horas en Helpdesk

    Descripción Funcional: Personalizacion del registro de hojas de horas en tickets.

    Navegación y Verificación

    helpdesk_halo_integration — Integración con Halo ITSM

    Ruta: Ajustes → Técnico → Halo Integration → configurar URL + API key de Halo

    1. Verifica la configuración de conexión en Ajustes → Halo
    2. Crea un ticket en Odoo — debe sincronizarse con Halo automáticamente via cron
    3. Comprueba el campo halo_ticket_id en el ticket de Odoo

    itc_helpdesk_solution_tab — Pestaña Solución

    Ruta: Servicio de atención → Tickets → [cualquier ticket] → pestaña Solución

    1. Abre un ticket de soporte
    2. Navega a la pestaña "Solución"
    3. Documenta la solución aplicada y guarda

    itc_ticket_user — Usuario Final del Ticket

    Ruta: Servicio de atención → Tickets → ticket → campo Ticket User justo debajo de Property User

    1. Asigna el Property User → el desplegable de Ticket User solo muestra sus contactos hijos
    2. Selecciona un contacto sin email → aviso bloqueante "Email Required for Ticket User"
    3. Crea un contacto al vuelo dejando el email vacío → bloqueo "Email Required for New Contact"
    4. Edita un contacto ya usado como Ticket User y vacía su email → bloqueo con recuento de tickets afectados
    5. Fix multi-compañía: Nuevo desde el kanban → clic en Cliente → el autocomplete abre sin el error company_id is not defined

    itc_mastel_helpdesk_pes_tech_support — Support Status y aviso Extended Support

    Rutas:

    • Fechas de un cliente: Contactos → hotel → pestaña Support Status
    • Listado global: Contactos → menú Support Status
    • Destinatario del aviso: Ajustes → Técnico → Parámetros del sistema → itc_mastel_helpdesk_pes_tech_support.extended_support_email
    1. En la ficha de un hotel con PES contratado, en la pestaña Support Status debe haber una fila por cada tag. Como usuario Projects/Admin edita una Fecha Fin → el cambio queda en el chatter del cliente.
    2. Añade una fila nueva → el tag aparece automáticamente en x_studio_support_status_; elimínala → el tag se retira si nadie más la usa.
    3. Crea un ticket cuyo Property User sea ese hotel → salta el pop-up con servicios, fechas y Notas Internas, y Extended Support recibe el correo bilingüe.
    4. Ticket sin Property User → asígnalo después → el pop-up salta al instante sin recargar y el email sale UNA sola vez (flag extended_support_notified).
    5. Contactos → Support Status → filtra por "Caducado" y agrupa por Cliente para revisar renovaciones.
    6. Intenta añadir un tag de Support Status a un Individuo → ValidationError "solo puede asignarse a contactos tipo Empresa".
    7. Verifica en el email recibido por Extended Support que aparece la línea Título del Ticket / Ticket Title con el asunto del ticket, entre Support Status y Número de Ticket (v17.0.1.18.0, #43073).

    itc_mastel_pes_weekly_report — Informe PES semanal

    Rutas:

    • Cron: Ajustes → Técnico → Automatización → Acciones planificadas → "Mastel — Envío semanal Informe PES"
    • Override histórico: Ajustes → Técnico → Parámetros del sistema → pes_report.today_override (formato YYYY-MM-DD)
    1. Botón "Ejecutar manualmente" sobre el cron → en el log aparece [PES] Generando informe … y [PES] Enviado: N líneas, X h PES.
    2. Verifica la recepción del correo "Informe PES - DDMMAAAA" con PDF adjunto Informe_PES_AAAAMMDD.pdf.
    3. Regenera un informe histórico: crea pes_report.today_override = 2026-04-27, lanza el cron manualmente y bórralo al terminar.
    4. Renombra temporalmente uno de los multipliers "PREMIUM CS/ACS …" → el informe siguiente saldrá vacío (verificación del filtro).
    5. Revisa la comparativa mensual: el mes en curso debe salir marcado como "(parcial, N semana(s))".

    itc_development_request — Portal Solicitudes de Desarrollo

    Ruta: Portal público → mastel.odoo.com/development-request (como usuario portal)

    1. Inicia sesión como usuario portal en mastel.odoo.com
    2. Navega a /development-request
    3. Envía una solicitud de prueba y verifica que aparece en Helpdesk → Tickets

    helpdesk_counting — Conteo de Tickets

    Ruta: Servicio de atención → [vista Kanban] → contadores en cabecera de cada columna

    1. Cambia a vista Kanban en Helpdesk
    2. Verifica los contadores numéricos en cada etapa

    bi_website_ticket_problem_solution_ent — FAQ Portal

    Ruta: Portal → ticket → sección Problema / Solución visible para el cliente

    1. Rellena los campos Problema y Solución en un ticket resuelto
    2. Entra al portal como cliente y verifica que puede ver ambas secciones