Antes de añadir un chatbot público de Drupal, aprueba la información que debe utilizar un visitante anónimo. Un nodo publicado, un resumen visible, un archivo descargable y la vista de miembro de esa misma página son superficies de evidencia diferentes. Regístralas por separado, anota la salida anónima real y pide al responsable del contenido que apruebe la fuente pública. La ubicación de un widget no establece qué puede contener su colección de respuestas.
Autor: Achla AI, organización. Revisión: 14 de octubre de 2026. Elaborado con ayuda de IA a partir de documentación oficial de Drupal y fuentes de producto de Achla. Es una hoja original de aprobación de fuentes. Sus escenarios son hipotéticos, no resultados de clientes observados ni pruebas de acceso completadas.
El alcance del chatbot público empieza con pruebas del visitante anónimo
Un chatbot público no debe comenzar con «indexar todos los nodos publicados». Empieza con una pregunta más limitada: ¿qué información ha aprobado su responsable para las preguntas de visitantes anónimos?
Usa un navegador corriente sin iniciar sesión para la superficie pública propuesta y una sesión de miembro autorizada e independiente para comparar. No entregues cookies ni credenciales de miembros a un servicio de fuentes públicas. La comparación es una revisión del responsable, no una forma de dar acceso privado al asistente.
Registra la URL, la información visible y el público previsto. Si la página es accesible pero contiene información que su responsable nunca quiso compartir, esa accesibilidad es un problema que resolver, no una aprobación para usarla. Si exige pertenencia de forma intencional, mantenla restringida.
Separa esta hoja de una investigación de respuestas ausentes. Su resultado es fuente aprobada, fuente excluida o requisito en espera, antes de elegir producto. No es una receta para diagnosticar un índice ni facilitar la recopilación de una página restringida.
Registra nodos, tipos, campos, bloques y API por separado
Crea una fila para cada representación que pueda contener un hecho sustancialmente distinto. Los modos de visualización de Drupal determinan cómo se muestra el contenido, como contenido completo o resúmenes; los formateadores controlan la apariencia de los campos. Un listado breve no debe sustituir la inspección completa de una página. Modos de visualización y formateadores de Drupal.
Usa esta lista de superficies para decidir qué filas necesita tu sitio:
| Superficie | Qué registrar | Por qué importa una fila separada |
|---|---|---|
| Página completa de nodo | Tipo de contenido, URL y campos visibles | Un título público no establece que todos los campos sean públicos. |
| Resumen o listado | URL del listado y resumen mostrado | Un resumen puede mostrar otra redacción u omitir una condición. |
| Bloque reutilizable o de página | Página anfitriona y texto visible del bloque | Un anuncio público puede aparecer fuera del nodo original. |
| Archivo referenciado | URL real de descarga y resultado anónimo | La descarga es una superficie de acceso distinta de la página que enlaza. |
| Revisión publicada | URL pública y redacción actualmente visible | La copia de trabajo del editor puede diferir de la representación en vivo. |
| Representación API, si procede | Endpoint, campos y consumidor previsto | La salida del navegador no demuestra la exposición de cada campo API. |
Drupal describe los bloques como fragmentos de contenido que se colocan en regiones del tema. Registra las páginas anfitrionas reales sin asumir que una barra lateral o un pie están fuera del límite de fuentes. Concepto de bloque de Drupal.
JSON:API respeta el acceso a entidades y campos y no crea su propia capa de autorización. Es una prueba útil sobre esa API, no una garantía de que todos los endpoints personalizados o páginas representadas tengan salida idéntica. Incluye una fila API solo cuando sea pertinente para la fuente prevista o la revisión de exposición; este artículo no afirma que Achla importe JSON:API de Drupal. Consideraciones de seguridad de JSON:API.
El estado de publicación y los permisos del rol responden preguntas distintas
Drupal distingue usuarios anónimos y autenticados, con permisos asignados mediante roles. La visualización satisfactoria de un editor no sustituye la observación anónima. Registra el tipo de sesión en cada fila de pruebas. Usuarios, roles y permisos de Drupal.
Registra aparte el estado de publicación. Content Moderation puede mantener una versión publicada mientras otra copia de trabajo está en revisión. Quien revisa la versión más reciente puede aprobar una redacción que el público aún no ve. Las traducciones también pueden tener estados de moderación separados. Vincula la aprobación a la redacción pública y al idioma realmente revisados. Descripción de Content Moderation.
Los archivos requieren una decisión propia. La documentación de File explica que cualquiera que conozca la URL puede descargar directamente archivos públicos. Ocultar un adjunto de una lista visible no demuestra protección de descarga. También advierte que el almacenamiento privado por sí solo no garantiza denegación: Drupal necesita un motivo aplicable para restringir la descarga. Pide al mantenedor que verifique la configuración real, sin tratar una etiqueta de directorio como resultado. Descripción del módulo File.
La hoja separa tres preguntas: ¿en qué estado está el contenido, qué puede ver este usuario y qué ha aprobado su responsable para respuestas públicas? Un «sí» en una columna no rellena las demás.
Completa el registro de aprobación de fuentes públicas
Usa una fila por cada representación importante. El siguiente registro es un ejemplo ilustrativo de una asociación profesional hipotética. Las observaciones son inventadas únicamente para mostrar cómo funciona la hoja; no son hallazgos de pruebas.
| Contenido o superficie | Público previsto | Observación anónima ilustrativa | Observación de miembro autorizado ilustrativa | Responsable y decisión |
|---|---|---|---|---|
| Nodo de política de membresía, vista completa | Cualquier persona que considere asociarse | Se muestran elegibilidad pública y renovación anual | Misma redacción pública | Responsable de membresía: incluir solo hechos públicos revisados |
| Resumen del directorio | Todos | Nombre de organización y resumen público visibles | Más datos de miembros en otro lugar | Responsable del directorio: aprobar alcance del resumen; inspeccionar registro completo aparte |
| Nodo de ventajas para miembros | Miembros | Se exige iniciar sesión | Condiciones detalladas de ventajas visibles | Responsable de membresía: excluir del asistente público |
| Página de evento con campo interno de planificación | Datos públicos del evento; planificación solo para personal | Fecha pública visible; campo de planificación ausente | Personal autorizado ve planificación | Responsable del evento: aprobar campos públicos visibles; excluir planificación privada |
| Bloque de anuncio en cabecera | Todos | Aviso actual de inscripción visible | Mismo aviso | Responsable de comunicación: aprobar redacción y ubicación anfitriona |
| Descarga de manual público | Todos | URL directa abre sin iniciar sesión | Mismo archivo | Responsable del manual: aprobar archivo aparte del nodo que lo enlaza |
| Política revisada pendiente | Solo revisión pública aprobada | Redacción anterior aprobada visible | Editor puede inspeccionar propuesta | Responsable de política: aprobar solo versión en vivo; repetir tras publicación posterior |
Añade URL exactas, identificadores de tipos o campos cuando sean útiles, fecha, ubicación de pruebas y responsable de permisos. Deja las observaciones sin resolver visiblemente como desconocidas. No sustituyas una celda vacía por «publicado, por tanto público».
En un registro real, usa observaciones breves y objetivas: «la página anónima muestra título y cuerpo; campo X ausente», no «seguro». La primera es repetible; la segunda oculta el alcance. Mantén los valores sensibles de miembros fuera del registro público. Anota superficie y resultado de acceso sin copiar contenido privado a la fuente propuesta del chatbot.
Ejecuta escenarios emparejados de anónimo y miembro
Elige varias situaciones representativas, no solo tu página pública más sencilla. Los ejemplos explican qué comprobar; no informan de resultados completados.
Nodo de política pública. Abre la URL prevista sin iniciar sesión e identifica un hecho sobre el que debería poder preguntar el visitante. Compáralo con la vista de miembro. Si la redacción coincide y el responsable la aprueba, la fila puede avanzar hacia inclusión. Si el miembro ve material adicional, registra qué representación contiene el hecho aprobado.
Nodo exclusivo para miembros. Verifica el resultado anónimo e inspecciónalo después con una cuenta de miembro autorizada. Si la tarea depende del texto privado, excluye la fuente de la evaluación del widget público. Puede necesitarse otro producto con recuperación autenticada verificada; la guía de arquitectura de Drupal aborda esa decisión operativa más amplia.
Página con un campo restringido. Compara la salida del campo, no solo título o código de estado. Pregunta a su responsable si la representación anónima es intencional. Si aparece públicamente una nota interna de planificación, detén la aprobación de la fuente y avisa al mantenedor mediante el proceso existente del equipo. No trates una exposición accidental como permiso de uso.
Documento referenciado. Prueba la URL real de descarga en la sesión anónima. Una barrera de inicio de sesión en la página superior no resuelve, por sí sola, el acceso a una URL de archivo público. Registra el resultado y la decisión del responsable sin cambiar almacenamiento ni permisos durante la revisión.
Estas parejas revelan el alcance de fuentes. No demuestran que un chatbot aplique permisos individuales. Aquí no se afirma tal capacidad de Achla.
Asigna inclusión, exclusión, corrección pública o espera de flujo privado
Da a cada fila una decisión explícita y una siguiente acción del responsable:
| Decisión | Significado | Siguiente acción |
|---|---|---|
| Incluir | Representación ya pública aprobada intencionalmente para la tarea | Conservar superficie exacta, alcance de redacción, responsable y fecha en las entradas de evaluación |
| Excluir | Material privado, innecesario o no aprobado | Mantenerlo fuera de las fuentes públicas propuestas; conservar la decisión |
| Corregir contenido público | Información destinada al público ambigua o contradictoria entre superficies públicas | Pedir al responsable corregir y aprobar la redacción antes de evaluar |
| Mantener flujo privado en espera | Tarea esencial requiere fuente autenticada o resultado personal | Detener esta vía exclusivamente pública e investigar un flujo verificado aparte |
«Corregir contenido público» no significa relajar controles de acceso. Por ejemplo, una página hipotética de evento puede mostrar un plazo y su bloque público de cabecera otro. El responsable de comunicación debe resolver el hecho público previsto. No se debe pedir al asistente elegir qué fecha es oficial.
«Incluido» tampoco significa recopilado o respondido con éxito. La aprobación establece que se permite usar el contenido para la tarea. Las pruebas posteriores del producto establecen si la vía documentada puede utilizarlo y devolver una respuesta adecuada. Conserva ambos resultados como pruebas separadas.
Un producto exclusivamente público puede seguir encajando en un sitio con páginas de miembros. La pregunta es si el trabajo elegido se resuelve mediante superficies públicas aprobadas. Si no, no amplíes la capacidad documentada mediante interpretaciones optimistas.
Actualiza las pruebas y la responsabilidad al cambiar publicaciones
Revisa las filas afectadas tras cambios en visualización de tipos, campos, bloques, roles, archivos o publicación. Registra qué decisión anterior sigue vigente y qué representación necesita otra comprobación anónima. Conserva las pruebas anteriores para que el responsable pueda explicar el cambio.
Incluye la vía habitual de entrega anónima. Drupal documenta variaciones de caché mediante contextos y señala que Internal Page Cache supone páginas idénticas para visitantes anónimos. La salida reciente de un editor autenticado no establece el resultado anónimo almacenado en caché. Pide al mantenedor investigar discrepancias; esta hoja no prescribe cambios de caché ni permisos. Contextos de caché de Drupal.
Los informes históricos de incidencias de módulos pueden señalar preguntas que comprobar, pero no prueban un error en tu instalación actual. Prefiere una observación fechada de tu propia superficie aprobada y la decisión del responsable.
Evalúa el conector público de Drupal solo después de aprobar fuentes
Cuando el registro respalde una tarea de información pública, consulta la página existente de Achla para Drupal y las instrucciones actuales de instalación. El producto respaldado es un widget gestionado de respuestas sobre contenido del sitio con enlaces a fuentes. Este artículo no afirma que el conector herede roles de Drupal ni imponga recuperación privada por usuario.
Utiliza la documentación de resolución de problemas para comprobaciones posteriores y los precios actuales para las condiciones. Si encaja el límite público, inicia la incorporación; puede requerirse iniciar sesión. Lleva el registro aprobado a la evaluación. Mantén excluidas las fuentes exclusivas para miembros.
