Obtén ayuda con WebBlocks Support

Mantén la conversación de soporte junto al trabajo del CMS al que se refiere. WebBlocks Support permite a los usuarios conectados informar de problemas, proponer mejoras o hacer preguntas y seguir las respuestas del proveedor desde el panel de administración. Un administrador conecta la instalación una vez; cada usuario autorizado ve sus propias solicitudes.

El ejemplo es Northstar Studio. Instalarás Support, conectarás un proveedor, informarás de un problema de vista previa, responderás a una pregunta y decidirás si compartes una captura de diagnóstico limitada. También interpretarás estados, reconocerás una interrupción del proveedor y revisarás las consecuencias de desconectarlo.

La guía utiliza el archivo publicado de Support 0.3.6 sobre WebBlocks CMS 1.105.37, con interfaz inglesa, tema claro y contenido ficticio. Northstar Demo Support es un proveedor simulado para esta guía. Las pantallas pertenecen al complemento real; una configuración de prueba local aporta la aprobación, respuestas y cambios de estado. Ninguna organización real recibió solicitudes ni diagnósticos. Confirma con tu proveedor la incorporación, los tiempos de respuesta y los derechos del plan real.

Consulta el contrato técnico en la referencia de Support y el protocolo de Support. El flujo general de instalación está en Sistema de complementos.

Antes de empezar

Utiliza primero una instalación de prueba. Instalar y activar complementos requiere Super admin. Support 0.3.6 declara CMS ^1.92.1 y PHP >=8.4; el catálogo indica Laravel ^13.0. Comprueba los requisitos del CMS y del alojamiento antes de instalar el paquete del catálogo de complementos de WebBlocks.

Necesitas un proveedor compatible con WebBlocks Support Protocol 1.0, su dirección HTTPS y un código de invitación de un solo uso proporcionado por él. Instalar el complemento gratuito no crea una cuenta, activa un plan ni garantiza la aceptación de solicitudes. El proveedor define las condiciones y prestaciones disponibles.

Los usuarios del CMS no necesitan iniciar una sesión independiente con el proveedor para este flujo. La instalación se conecta y el complemento identifica al usuario que informa. Una URL de asistencia genérica no basta: el servidor debe ofrecer las API compatibles de descubrimiento, activación y tickets.

Support es un cliente de asistencia para usuarios del CMS. No añade un widget público, formulario de tickets para visitantes ni consola de agentes del proveedor. Para consultas de visitantes, utiliza la guía de Forms o Formularios de contacto y mensajes.

1. Instala y activa Support

  1. Abre System → Plugins como Super admin.
  2. Selecciona Browse Plugin Catalog, busca WebBlocks Support y revisa versión, compatibilidad y notas de publicación.
  3. Utiliza Install from Catalog, abre los detalles del complemento instalado y elige Enable Plugin.
  4. Si tu administrador proporciona el ZIP publicado de confianza, selecciónalo en Plugin ZIP, pulsa Upload Plugin ZIP, revisa los detalles y activa el complemento.

El ejemplo usa el ZIP publicado. La primera pantalla muestra Support instalado pero aún desactivado junto al formulario de instalación manual.

Pantalla de complementos con Support 0.3.6 instalado pero desactivado y los controles para cargar el ZIP

La instalación y activación del CMS actual aplican los cambios de base de datos del complemento. Revisa las advertencias de migración o configuración antes de usar Support. No modifiques filas para eludir una instalación fallida. Los detalles deben mostrar la versión esperada, el ciclo Enabled y un resultado de salud que confirme almacenamiento e interfaz preparados.

Detalles de Support con versión 0.3.6, ciclo Enabled y resultado Healthy para almacenamiento e interfaz

La salud del complemento comprueba la configuración local. No demuestra que el proveedor externo sea accesible ni que haya aprobado la instalación. Abre el nuevo elemento Support de la navegación para continuar.

2. Asigna los permisos adecuados

Support tiene dos permisos de complemento:

Permiso Acciones permitidas Asignación habitual
webblocks-support.access Abrir Support, crear solicitudes, leer las propias, responder y decidir sobre diagnósticos. Usuarios del CMS que deban contactar con soporte.
webblocks-support.manage Conectar, comprobar la activación y desconectar el proveedor de la instalación. Operador responsable de la conexión.

Da al gestor de la conexión acceso a Support además del permiso de gestión. La pantalla Support necesita el permiso de acceso. Consulta Roles y permisos antes de cambiar un rol existente.

El usuario habitual no necesita permiso para cambiar el proveedor. Sin gestión de conexión no ve sus controles. Si la instalación no está conectada, verá que las solicitudes no están disponibles.

La lista de tickets es personal del usuario conectado al CMS. Support delimita las solicitudes por instalación e informante; no es una cola compartida de todos los usuarios. Super admin no convierte la lista en una bandeja de agentes del proveedor. Otra cuenta no puede abrir un ticket ajeno mediante el complemento solo por conocer su dirección.

3. Introduce la dirección y la invitación

Abre Support con una cuenta que tenga ambos permisos. Antes de activar, la tarjeta Support connection contiene dos campos:

  • Support provider address: dirección HTTPS facilitada por el proveedor compatible.
  • Support invitation code: invitación de un solo uso para esta instalación.
Formulario de conexión con los campos de dirección del proveedor y código de invitación vacíos

Introduce la dirección real del proveedor, pega el código y elige Connect support. La dirección debe resolver a un extremo público mediante HTTPS. Se rechazan localhost, redes privadas o reservadas, credenciales incrustadas y componentes URL inadecuados. No pegues una contraseña de administrador ni un token de API en el campo de invitación.

Enviar el formulario inicia descubrimiento y activación. El proveedor recibe identificación y contexto de la instalación, incluidos versión del CMS, URL del sitio y entorno. Abrir el formulario no envía la solicitud de activación. Utiliza solo el proveedor al que quieras conectar esta instalación.

Los códigos de invitación y activación son información de conexión. Exclúyelos de capturas y notas compartidas. La imagen anterior deja los campos vacíos deliberadamente.

4. Completa la aprobación del proveedor

Tras una solicitud válida, Support muestra una conexión pendiente y solicita la aprobación del proveedor. También ofrece Check activation y Disconnect. El operador del proveedor aprueba; Check activation consulta el resultado actual. Un estado pendiente no indica que la instalación del complemento haya fallado.

  1. Contacta con el proveedor mediante su proceso de incorporación acordado si hace falta aprobación.
  2. Vuelve a Support en el CMS.
  3. Selecciona Check activation cuando el proveedor apruebe la instalación.
  4. Confirma el mensaje de éxito y el estado active.
  5. Revisa el nombre del proveedor y cualquier nombre de plan devuelto.
Conexión activada con Northstar Demo Support, estado active y plan Studio Support

El proveedor del ejemplo devuelve Northstar Demo Support y Studio Support. Son nombres ficticios, no un plan incluido. La conexión activa habilita New request. Es normal que la lista esté vacía en este momento.

La activación puede caducar o rechazarse. Pregunta si la invitación sigue siendo válida, si se completó la aprobación o si necesitas otra invitación. La pantalla puede seguir ofreciendo quitar una conexión inutilizable. Resuelve el estado del proveedor antes de desconectar y reiniciar; reenviar repetidamente una invitación consumida no es una estrategia de recuperación.

5. Elige el tipo de solicitud

Selecciona New request. El formulario contiene Type, Subject y Details.

Tipo del formulario Uso Ejemplo
Problem Algo se comporta de forma distinta a lo esperado. El título guardado de un borrador no aparece en Preview.
Suggestion Una mejora para que la valore el proveedor. Una ruta más rápida de la edición a Preview.
Question Orientación sobre comportamiento o configuración. Si los editores pueden abrir sus propias solicitudes.

Elige el tipo que describa la solicitud. No es un selector de prioridad, garantía de respuesta ni aprobación automática de trabajo de pago. El proveedor decide cómo procesarla.

Mantén un tema claro por ticket. Un asunto útil describe la acción y el síntoma, como La vista previa del borrador muestra el título anterior. Un título como «Ayuda» dificulta el seguimiento.

6. Escribe detalles reproducibles

Utiliza Details para explicar qué hiciste, qué esperabas y qué ocurrió. Para el problema ficticio de Northstar introducimos:

Page: Autumn field notes (draft)
Steps: Open the page, update its title to Autumn studio notes,
save, then open Preview.
Expected: The preview heading shows Autumn studio notes.
Actual: The preview still shows Autumn field notes after a refresh.
Scope: One draft page in Northstar Studio.
No published content is affected.
First noticed: 27 October, around 09:00.
Formulario con tipo Problem, asunto concreto y pasos reproducibles de la vista previa del borrador

Es un informe de ejemplo, no una afirmación de que el CMS publicado tenga ese defecto. Sustitúyelo por tu observación real. Incluye página o función, hora aproximada, repetibilidad y efectos sobre contenido publicado. Indica sitio e idioma cuando proceda; Support usa una conexión de instalación, no un selector de sitio.

El asunto acepta hasta 255 caracteres. Los detalles iniciales y cada respuesta admiten hasta 20,000 caracteres. El formulario no tiene campo para adjuntos. Describe una captura en texto o usa un método independiente acordado expresamente con el proveedor. No pegues secretos, registros personales, logs completos ni configuración sin procesar.

Revisa y elige Send request una sola vez. La carga incluye tu nombre visible del CMS, una referencia de informante limitada a la instalación y su contexto. La referencia mantiene tu lista separada de otros usuarios e instalaciones.

7. Confirma la creación de la solicitud

Un envío correcto abre el ticket y muestra Your request has been sent. El encabezado incluye número y asunto. Los detalles iniciales aparecen en Conversation, bajo You y Reporter.

Solicitud nueva 1001 con confirmación, detalles iniciales y estado Waiting for support

El ejemplo es #1001 y muestra inicialmente Waiting for support. Conserva el número al hablar con el proveedor del mismo problema. Utiliza Back to requests para volver a la lista y el enlace del asunto para reabrir la conversación.

Si falla el envío, el complemento vuelve al formulario conservando el texto y mostrando un error. Antes de reintentar tras un fallo incierto de conexión, comprueba la lista: la solicitud podría haber llegado aunque la respuesta final no alcanzara el navegador. Evita varios tickets para el mismo problema.

La pantalla confirma la creación del ticket en el proveedor. No confirma que un agente lo haya leído, que se haya entregado correo ni que exista un plazo acordado.

8. Lee la respuesta del equipo y contesta

Vuelve al ticket para comprobar novedades. El proveedor simulado añade una pregunta y cambia el estado a Waiting for your reply. La conversación diferencia al informante de un mensaje del Support team y muestra las horas.

Pregunta del equipo sobre el título guardado y estado Waiting for your reply en el ticket

Lee la pregunta antes de contestar. Si te piden probar una acción, explica el resultado y cualquier diferencia pendiente. Continúa en el mismo ticket para conservar el contexto.

  1. Busca Add a reply debajo de la conversación.
  2. Introduce el resultado de la comprobación.
  3. Revisa que no haya información confidencial.
  4. Elige Send reply.
  5. Confirma Your reply has been added. y que tu mensaje aparece.
Campo Add a reply con el resultado de reabrir Preview y botón Send reply

Añadir un mensaje no equivale a cambiar tú mismo el estado. El proveedor controla su flujo. En el ejemplo, nuestra respuesta devuelve la solicitud a espera de soporte; otro proveedor compatible puede tratar esa transición de otra forma.

No dependas de un correo o aviso del navegador para conocer la respuesta. El flujo ilustrado consiste en volver a la lista o al ticket. Las notificaciones adicionales dependen del proveedor y de su integración.

9. Revisa el diagnóstico antes de compartirlo

El proveedor puede pedir una captura de diagnóstico limitada para un ticket. Aparece encima de Conversation, en Diagnostic access requested. Ver la tarjeta no recopila ni envía la captura.

Tarjeta de consentimiento para versiones del sistema y estado de complementos, con Approve and share y Decline

Lee las categorías exactas de la tarjeta. El complemento reconoce tres:

Categoría de Support Información preparada
Versiones del sistema y entorno Versiones del CMS y PHP, nombre del entorno, estado de depuración y controlador de base de datos.
Versiones y activación de complementos instalados Identificadores, versiones, activación y resultado de compatibilidad.
Errores recientes con credenciales y correos ocultos Selección limitada de líneas recientes procesadas por las reglas de ocultación del recopilador.

El recopilador lee un tramo final limitado del log estándar y selecciona líneas de error; no sube el registro completo. Los límites son 64 KiB finales, hasta 40 líneas coincidentes y hasta 2,000 caracteres por línea. La ocultación trata marcadores habituales de credenciales, valores bearer y correos. El filtrado no justifica introducir material confidencial arbitrario en logs o tickets.

Una petición de diagnóstico no es acceso remoto. El recopilador no permite elegir archivos arbitrarios, subir archivos de entorno, ejecutar comandos de shell ni código controlado por el proveedor. Los campos de texto y respuesta son independientes: contienen lo que decidas enviar.

10. Aprueba solo la captura que deseas compartir

Si las categorías son adecuadas y tu organización permite compartirlas con ese proveedor, elige Approve and share. El complemento recopila las categorías reconocidas y envía la captura para esa petición concreta.

Ticket con confirmación de que la captura de diagnóstico aprobada se compartió con soporte

Confirma The approved diagnostic snapshot was shared with support. El proveedor aún debe revisarla. El mensaje no significa que el problema esté resuelto.

El ejemplo aprueba versiones del sistema y entorno y versiones y activación de complementos. No aprueba errores recientes en esa acción. La autorización corresponde a la petición mostrada, no a futuras peticiones ni vigilancia continua. Lee cada petición por separado.

La tarjeta enumera categorías, no una vista editable línea por línea. Completa cualquier revisión o aprobación independiente antes de elegir Approve and share.

11. Rechaza cuando no corresponda compartir

Puedes elegir Decline. En el segundo ejemplo, el proveedor pide errores recientes de la aplicación. Rechazamos esa petición.

Tarjeta que pide errores recientes ocultando datos sensibles y ofrece Decline

Después, comprueba The diagnostic request was declined. La respuesta de rechazo no incluye captura recopilada. La conversación existente sigue disponible.

Ticket que confirma el rechazo del diagnóstico mientras la conversación permanece visible

Si resulta útil, responde que puedes aportar pasos de reproducción u otra información autorizada. Rechazar el diagnóstico no equivale a rechazar o cerrar el ticket. El proveedor decide cómo seguir con la información disponible.

Si aprobar o rechazar produce un error de servicio, no supongas que recibió la decisión. Reabre el ticket, inspecciona su estado y consulta al proveedor si el resultado sigue sin estar claro.

12. Sigue los estados y confirma el resultado

Selecciona Back to requests. La lista muestra número, asunto, tipo, estado y hora de envío. El ejemplo incluye un problema cerrado, una pregunta en revisión, una sugerencia aceptada y otra rechazada.

Lista personal con tipos Problem, Question y Suggestion y estados Closed, In review, Accepted y Declined

Las etiquetas estándar son:

Etiqueta Interpretación
New El proveedor recibió una solicitud recién creada.
In review El proveedor pasó la solicitud a revisión.
Accepted El proveedor aceptó la solicitud en su flujo. Pregunta qué implica para alcance y entrega.
Declined El proveedor rechazó la solicitud. Lee la explicación de la conversación.
Closed El proveedor cerró la solicitud. Revisa el resultado antes de abrir otra por lo mismo.

El detalle usa Waiting for support para solicitudes nuevas o en revisión y Waiting for your reply cuando el proveedor espera al informante. Puede devolver valores adicionales; si no existe una etiqueta, el complemento puede mostrarlos directamente. Un estado no es un SLA ni un compromiso de entrega.

En el ejemplo ficticio, reabrir Preview muestra el título guardado. Informamos del resultado; el proveedor simulado añade un mensaje final y marca Closed.

Solicitud 1001 reabierta con estado Closed y conversación existente

El cliente no ofrece al informante un selector de estado ni botones para cerrar o reabrir. Puede seguir visible el campo de respuesta en un ticket cerrado, pero el proveedor decide si acepta otra respuesta o reabre el trabajo. Sigue sus instrucciones sin suponer que escribir cambia el estado.

13. Gestiona una interrupción sin perder contexto

La conexión puede permanecer active mientras un fallo de red o proveedor impide cargar la lista. La pantalla muestra The support service could not be reached. Please try again in a moment.

Conexión activa con aviso de servicio inaccesible y sin filas de tickets cargadas

Una lista no disponible no demuestra que se hayan eliminado los tickets. Espera, actualiza y comprueba de nuevo. Guarda las respuestas sin enviar fuera del navegador en un lugar suficientemente privado antes de salir. Indica al operador qué acción falló y cuándo, sin credenciales ni un volcado completo de logs.

La lectura directa de un ticket también puede fallar si el proveedor es inaccesible. Confirma su disponibilidad, el derecho de soporte y el origen configurado. Desconectar no repara una interrupción temporal y puede exigir otra invitación y aprobación para recuperarse.

14. Desconecta o cambia de proveedor deliberadamente

Solo el gestor de la conexión ve Disconnect. Al seleccionarlo aparece una confirmación que explica la pérdida de acceso hasta reactivar la instalación.

Confirmación Disconnect support que avisa de la pérdida de acceso hasta una nueva activación

Cierra el diálogo si solo lo inspeccionas. Para quitar la conexión, confirma Disconnect dentro. Si está activa, el complemento pide revocar la conexión al proveedor y luego elimina el registro local. Si la revocación falla, resuelve el error antes de dar por terminada la desconexión.

Desconectar no elimina tickets ni ordena borrar datos del proveedor. Quita esta conexión del CMS; el proveedor controla conservación e historial recuperable. Comprueba el acceso a trabajos abiertos y el tratamiento del historial antes de cambiar de proveedor o mover la instalación.

Para otro proveedor, completa primero la desconexión anterior, consigue la nueva dirección e invitación y repite la activación. No presupongas que heredará las conversaciones anteriores.

Solución de problemas

Síntoma Comprobación
Support no aparece Confirma activación, compatibilidad y disponibilidad en la siguiente petición; revisa el permiso de acceso.
Support abre sin controles de conexión Puede haber acceso a tickets sin gestión de conexión. Pide al gestor que active el proveedor.
No se verifica la dirección o invitación Usa la dirección HTTPS pública exacta, una invitación válida sin usar y un servicio Protocol 1.0. Revisa descubrimiento, salida de red y requisitos de aprobación con el operador.
La activación sigue pendiente Pregunta si el proveedor aprobó la instalación y usa Check activation. Comprueba si la caducidad exige otra invitación.
Proveedor activo pero sin New request Revisa estado, caducidad/derechos y cuenta conectada. El complemento instalado no equivale a conexión activa.
Tu lista está vacía y otra persona tiene tickets Las solicitudes pertenecen al informante. Entra con la cuenta que creó el ticket.
Un ticket conocido no se encuentra Comprueba cuenta, instalación y proveedor. Los tickets ajenos se ocultan deliberadamente.
Falla el envío Guarda el texto, revisa si aparece una solicitud ya enviada y reintenta cuando el proveedor sea accesible.
Falla compartir diagnósticos Reabre el mismo ticket, comprueba que la petición sigue presente y la disponibilidad del proveedor. No pegues logs sin procesar como alternativa.
Problema de almacenamiento o migración Pide al administrador resolver el flujo admitido de instalación/migración y acceso al almacenamiento. Conserva la identidad de instalación al mover o restaurar.

Comprobación completa del primer uso

Antes de ofrecer Support, confirma que el complemento publicado está activado, el proveedor activo y el rol previsto puede abrir solicitudes propias. Crea una prueba controlada, verifica su presencia en la lista del informante y pide al proveedor que responda. Envía una respuesta desde el CMS y confirma que llega.

Si hay diagnósticos, verifica el consentimiento con datos de prueba autorizados y comprueba compartir y rechazar. Acuerda por separado disponibilidad, notificaciones, tiempos de respuesta e información compartible. Son condiciones de la relación con el proveedor, no garantías del complemento.

Ya tienes una ruta repetible del problema del CMS a la conversación: informe claro, número visible, respuesta contextual y decisión consciente sobre diagnósticos. Continúa con Roles y permisos para delegar el uso o con el protocolo de Support si implementas un proveedor compatible.