Usuarios y permisos

WebBlocks CMS utiliza cuentas de administrador a nivel de instalación.

Estos usuarios sirven para gestionar el propio CMS. No son cuentas públicas de membresía y no se incluyen en los paquetes de sitio de Export / Import.

Como los usuarios afectan a toda la instalación, la pantalla Users se encuentra en la navegación System del panel de administración.

Cada usuario administrador del CMS que ha iniciado sesión gestiona los datos de su propia cuenta desde /webadmin/profile. La página Profile es independiente de la gestión de Users y solo expone el nombre y el correo electrónico del usuario actual, el formulario de cambio de contraseña con confirmación de la contraseña actual y las acciones Save Changes.

Los campos de contraseña de las pantallas Profile y Users utilizan el patrón Password Toggle de WebBlocks UI incluido de serie (data-wb-password-toggle con data-wb-target) del runtime de WebBlocks UI fijado. El núcleo del CMS no añade CSS ni JavaScript propios para mostrar u ocultar la contraseña.

Los Super Admins pueden gestionar roles personalizados en Roles y permisos del panel CMS. Cada usuario recibe un rol por sitio asignado; una misma persona puede publicar en un sitio y editar borradores en otro.

En la edición del usuario, seleccione los sitios y un rol para cada uno. Si deja vacío el rol por sitio, se utiliza el rol integrado seleccionado para el usuario. Super Admin es una pertenencia protegida independiente que se aplica a todos los sitios. No se puede eliminar ni desactivar al último Super Admin activo.

Inspeccionar permisos efectivos muestra las operaciones concedidas a un usuario y sitio sin iniciar sesión como ese usuario. La actividad de la cuenta, la pertenencia al sitio y el rol determinan el resultado. El estado de la página, las relaciones entre registros y los límites del token se verifican al ejecutar la operación. El historial registra concesiones, revocaciones y cambios de rol por sitio.

La activación y desactivación de cuentas y los cambios de pertenencia a Super Admin tienen acciones de historial propias con valores anteriores y nuevos. Filtre por acción para revisarlas por separado de las asignaciones por sitio. El historial sigue siendo de solo lectura y se mantienen las protecciones del último Super Admin activo.

Los tokens personales de API siguen limitados por sus capacidades y sitios permitidos junto con los permisos SQL actuales del usuario. Revocar un permiso lo retira también de los tokens personales existentes. Los tokens de sistema conservan sus reglas independientes. Los roles CMS no conceden privilegios en la administración de la aplicación anfitriona.

super_admin tiene acceso completo a nivel de instalación.

Este rol puede acceder a:

• Users
• sitios e idiomas (locales)
• ajustes
• actualizaciones
• copias de seguridad
• exportación/importación
• todo el contenido de los sitios de la instalación

Solo los usuarios super_admin pueden abrir /webadmin/users y gestionar otras cuentas del CMS.

La gestión de Users sigue siendo administración a nivel de instalación. Permite gestionar roles, sitios asignados, el estado activo o inactivo, la protección contra borrado y los restablecimientos de contraseña definidos por el administrador sin necesidad de la contraseña actual del usuario afectado. Esos campos de gestión del sistema no están disponibles desde la página Profile.

site_admin está limitado a un sitio.

Este rol puede:

• acceder a /webadmin
• gestionar el contenido de los sitios asignados
• publicar páginas de los sitios asignados
• mover páginas entre estados del flujo de trabajo en los sitios asignados

Este rol no puede acceder a áreas del sistema a nivel de instalación como Users, ajustes, actualizaciones, copias de seguridad o exportación/importación.

editor también está limitado a un sitio.

Este rol puede:

• acceder a /webadmin
• trabajar con el contenido de los sitios asignados
• editar páginas mientras están en draft
• enviar páginas a revisión
• devolver una página in_review a draft

Este rol no puede publicar ni archivar páginas, y no puede acceder a las áreas del sistema a nivel de instalación.

• super_admin siempre tiene acceso a todos los sitios
• site_admin y editor deben tener al menos un sitio asignado
• las áreas de administración limitadas a un sitio se filtran y se aplican en el servidor según el acceso a los sitios asignados

Este límite de sitio se aplica a las principales áreas de contenido, como páginas, navegación, medios, informes de visitantes y mensajes de contacto.

Las páginas, las revisiones de página, los Shared Slots y las revisiones de Shared Slot pueden almacenar referencias anulables a usuarios del CMS para la atribución de auditoría.

• Estas referencias las gestiona el sistema y no son campos de página editables.
• Los registros de contenido permanecen intactos si se elimina un usuario referenciado.
• Las claves externas de auditoría usan el comportamiento null-on-delete, de modo que la interfaz de administración antigua puede mostrar Not recorded para actores eliminados o desconocidos.

Puede:

• gestionar usuarios y roles
• acceder a todos los sitios
• usar las herramientas del sistema a nivel de instalación
• publicar y archivar páginas

No puede:

• eliminar, desactivar ni degradar al último super_admin activo

Puede:

• gestionar el contenido de los sitios asignados
• publicar páginas de los sitios asignados
• devolver páginas a borrador
• archivar páginas de los sitios asignados

No puede:

• acceder a Users
• acceder a las pantallas del sistema a nivel de instalación
• gestionar contenido fuera de los sitios asignados

Puede:

• crear y editar contenido en borrador de los sitios asignados
• enviar páginas a revisión
• devolver una página in_review a borrador

No puede:

• publicar páginas
• archivar páginas
• editar directamente contenido de páginas que no estén en borrador
• acceder a las pantallas del sistema a nivel de instalación

Los usuarios no son contenido de página ni registros de contenido sitio por sitio.

Definen quién puede operar la instalación, qué áreas del sistema están disponibles y en qué sitios puede trabajar cada persona. Eso hace que Users forme parte del modelo de administración a nivel de instalación, por lo que pertenece a System junto con las demás herramientas de todo el sistema.