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