signage_view — Vista de listado de pantallas en Digital Signage

Firma y ubicación

def signage_view(request):
    """Renderiza la página de Digital Signage (listado de pantallas).
    
    GET /monitoring/signage
    Template: templates/monitoring/signage.html
    """

Ubicación: monitoring/views.py:395–514

Propósito

Endpoint principal de la UI de Digital Signage. Agrega datos de monitoreo (CPU, memoria, status) de todos los dispositivos de la organización del usuario, y expone metadatos (vendor, modelo, capacidad de push) para renderizar el listado con badges informativos.

Autorizado a nivel de tenant (@views.paginate_request).

Cambio v1.64.0: Badge de capacidad push

Antes: listado mostraba vendor y modelo, pero no hacía explícita la capacidad de despliegue.

Ahora:

• Carga lista de adapters enabled una sola vez.
• Por cada dispositivo: resuelve adapter con resolve_signage_adapter(profile, adapters=enabled_adapters).
• Calcula push_state:
  • "push" si adapter resuelve y supports_real_push(adapter.slug).
  • "monitor" si adapter resuelve pero sin API de contenido.
  • "" si no hay adapter resuelto.
• Añade push_state al dict de contexto → template renderiza badge HTML + CSS.

Impacto en lógica:

• Sin cambios en provisioning, status, profundidad de datos.
• Solo suma nuevo campo booleano en el contexto (no afecta modelos).

Flujo detallado (v1.64.0)

1. Setup (línea 395–420)

org = request.user.organization
profiles = MonitoringTarget.objects.filter(organization=org).select_related(...)

Filtra perfiles de monitoreo activos en la organización.

2. Provisioning (línea 421–422)

if can_provision:
    provision_profile_targets(org, profiles)

Crea targets de monitoreo faltantes (pasos de onboarding).

3. Preload adapters (línea 423–430)

from signage.models import SignageVendorAdapter
enabled_adapters = list(SignageVendorAdapter.objects.filter(enabled=True))

Línea nueva v1.64.0: carga adapters una sola vez. Antes cada resolución hacía query.

4. Iteración de dispositivos (línea 431–475)

Para cada perfil:

• Extrae vendor, modelo, status de salud.
• Línea 463 (NEW): adapter = resolve_signage_adapter(p, adapters=enabled_adapters).
• Línea 464 (NEW): calcula push_state invocando supports_real_push(adapter.slug).
• Añade push_state al dict antes de append.

5. Renderizado (línea 476+)

Pasa devices[] a template.

Campos en contexto por dispositivo

devices.append({
    "id": p.id,
    "name": p.hostname or p.ip_address,
    "ip": str(p.ip_address),
    "vendor": p.vendor or "",
    "model": p.model or "",
    "push_state": push_state,          # ← NEW v1.64.0
    "status": status,
    "cpu_usage": cpu_usage,
    "memory_usage": memory_usage,
    "status_color": status_color,
    "port_connection": dev_port_connection or {},
    "alerts": alerts,
    "monitored_since": p.created_at,
})

Datos de origen

Autenticación y autorización

• Requerida: usuario logueado (@login_required).
• Scope: solo dispositivos de la org del usuario (organization=org).
• Si user es tenant-bound: filtrado automático por RLS en MonitoringTarget.objects.filter().

Template y CSS asociados

• Template: templates/monitoring/signage.html (línea 85–90) — renderiza badge inline.
• CSS: static/css/pages/signage.css (línea 151–169) — estilos .push-badge.push-real (verde) y .push-monitor (gris).

Performance notes

• Query count: antes ~1 + N (N = num. adapters queries). Ahora 1 (carga única) + iteración en memoria.
• Template render: ~10ms+ según tamaño de org (sin cambios respecto a v1.63.x).
• Recomendación: si org tiene >5000 dispositivos, considerar pagination en frontend (ya implementado con @paginate_request).

Véase también

• [[feature—signage—etiqueta-honesta-push-v164]]
• [[entity—monitoring—service—resolve-signage-adapter]]
• [[entity—signage—service—supports-real-push]]
• [[entity—signage—model—signage-vendor-adapter]]
• [[concept—saas—multi-tenancy]]