Un gestor documental necesita dos cosas que una web normal no suele necesitar: que cada persona vea y haga solo lo que le corresponde, y que un documento no se publique hasta que alguien lo apruebe. En Drupal lo primero se resuelve con roles y permisos, y lo segundo con los módulos del núcleo Workflows y Content Moderation, activados en el capítulo 2.
Cerrar el sitio a los anónimos
Lo primero, si el repositorio es interno: en /admin/people/permissions, quita al rol Usuario anónimo el permiso Ver contenido publicado. A partir de ahí, quien no haya iniciado sesión solo verá el formulario de acceso, y los enlaces de descarga de los ficheros privados le devolverán «Acceso denegado». Es la comprobación que quedó pendiente al final del capítulo 4.
Los roles
Los papeles del planteamiento se traducen así. El de lector no necesita un rol propio: cualquier usuario con sesión iniciada lo es.
| Rol | Permisos principales |
|---|---|
| Usuario autenticado (lector) | Ver contenido publicado. Nada más. |
| Autor | Documento: crear contenido nuevo · Documento: editar contenido propio · Ver contenido propio no publicado · Etiquetas: crear términos · Transiciones Crear borrador y Enviar a revisión |
| Revisor | Todo lo del autor, más: Documento: editar cualquier contenido · Ver cualquier contenido no publicado · Ver la última versión · Documento: ver y revertir revisiones · Proyecto o cliente: crear términos · Acceder a la página de resumen de contenido · Transiciones Devolver, Publicar, Archivar y Restaurar |
| Administrador | El rol que crea la instalación. Reservado a quien mantiene la estructura. |
Los roles se crean en /admin/people/roles/add, y los permisos de cada uno se asignan en /admin/people/permissions/ seguido del nombre de sistema del rol. Dos criterios que ahorran sustos:
- No des permisos de borrado a autores ni revisores. Un documento que sobra se archiva; borrar elimina también su historial de revisiones.
- No des el rol de administrador a quien solo necesita publicar. El administrador puede cambiar permisos, y un error ahí afecta a todo el repositorio.
El flujo de aprobación
Al activar Content Moderation con el perfil standard suele crearse un flujo llamado Editorial, con los estados Borrador, Publicado y Archivado. Si no aparece, créalo en /admin/config/workflow/workflows/add con el tipo Content moderation. Después:
- Añade el estado «En revisión», sin marcar Publicado ni Revisión por defecto. Así, mientras se revisa, sigue visible para los lectores la versión publicada anterior, si la hay.
- Define las transiciones:
- Crear borrador: de Borrador o Publicado a Borrador.
- Enviar a revisión: de Borrador a En revisión.
- Devolver: de En revisión a Borrador.
- Publicar: de En revisión o Publicado a Publicado.
- Archivar: de Publicado a Archivado.
- Restaurar: de Archivado a Borrador.
- Aplica el flujo al tipo de contenido Documento, en el apartado Este flujo de trabajo se aplica a.
- Estado por defecto: Borrador.
- Vuelve a
/admin/people/permissions: cada transición tiene ahora su propio permiso, que se asigna según la tabla anterior.
Lo mejor del flujo: editar un documento publicado no lo retira. La nueva versión se guarda como borrador, pasa por revisión, y los lectores siguen viendo la versión vigente hasta que se publica la nueva. Los revisores tienen la lista de lo pendiente en /admin/content/moderated.
Si algunos tipos de documento no necesitan aprobación, como las actas internas, hay dos opciones: dar a los autores la transición Publicar directamente desde Borrador, o crear un segundo tipo de contenido con otro flujo. La primera es más sencilla. La segunda deja más claro qué pasa por revisión y qué no.
Si no todos pueden ver todo
Los roles del núcleo controlan qué puede hacer cada usuario con un tipo de contenido, pero no permiten decir «este documento solo lo ve el área de Personas». Para eso hace falta un módulo contribuido de control de acceso. El más utilizado es Group, que organiza usuarios y contenidos en grupos con sus propios permisos. Hay que tener en cuenta que:
- introduce su propio modelo de permisos, que conviene diseñar con calma y probar con usuarios de cada tipo;
- afecta a los listados y a la búsqueda: los capítulos 6 y 7 explican cómo evitar que aparezcan títulos de documentos que el usuario no puede abrir;
- como con cualquier módulo contribuido, hay que comprobar su compatibilidad con la versión de Drupal instalada.
Usuarios y acceso
- Alta de usuarios: en
/admin/people/create, asignando el rol en el mismo formulario. - Cuenta corporativa: si la empresa usa Microsoft Entra ID, Google Workspace u otro proveedor de identidad, existen módulos contribuidos de OpenID Connect y de SAML para iniciar sesión con esa cuenta. Evita gestionar contraseñas aparte y facilita dar de baja a quien deja la empresa.
- Doble factor: si el gestor es accesible desde internet, conviene exigirlo al menos a revisores y administradores, con un módulo como TFA.
Con permisos y flujo configurados, el gestor ya está listo para recibir documentos, que es lo que cubre el capítulo siguiente.
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.
