OpenCms 9.5 ha traido como sorpresa la creación de nuevos roles de usuarios con los que podremos configurar mejor que tipo de permisos de cada uno de los usuarios editores de nuestro sitio web. La lista de roles por tanto queda ahora de la siguiente forma:

Roles disponible solo para la Unidad Organizativa Raíz

• Root administrator: Los usuarios con este rol tienen todos los permisos para manegar OpenCms. Un usuario con este rol asignado tendrá el equivalente a todos los demás roles asignados y no se tendrá en cuenta ninguna otra configuración de permisos a nivel de recursos.
• Database manager: Pueden importar y exportar módulos y contenido
• Workplace manager: Pueden manegar las tareas programadas, la administración de índices de búsqueda, crear nuevas propiedades, configurar el historial de recursos y las herramientas de administración del entorno de trabajo

Roles disponible para todas las OU

• Administrator: Un administrador tiene todos los permisos para su OU correspindiente, al igual que para el root administrator, toda la configuración de permisos es ignorada para los usuarios con este rol, es decir, tienen control total sobre sus recursos.
• Account manager: es un gestor de cuentas de usuarios, podrá añadir/borrar/editar usuarios dentro de su OU. Igualmentep podrá crear nuevos grupos y asignar usuarios.
• Project manager: Este rol ha sido muy importante en versiones antiguas de OpenCms, actualmente no se usa ya que no es necesario crear proyectos a mano.
• VFS resource manager: El usuario con este rol podrá manejar todos los recursos dentro de su OU. Podrán editar jsp, propiedades, atributos y permisos. Implica por herencia tener también todos los permisos que vienen a continuación.
• Template developer: El desarrollador de template podrá añadir y editar las páginas modelos además de los permisos siguientes.
• Workplace user: este rol permite al usuario poder acceder al tradicional workplace. No  podrá acceder al sitio raíz ni a los sitios que no sean de su OU. Tiene limitado el acceso a la vista de administración. Tendrá por defecto también los permisos siguientes.
• Category editor: El editor de categorías podrá acceder solo a la vista del ADE y podrá crear, editar y borrar  las categorias desde la vista del sitemap editor. Incluye también todos los permisos siguientes.
• Gallery editor: al igual que el anterior, podrá crear, editar y borrar las galerías directametne desde el ADE en la vista del sitemap editor. También hereda los permisos siguientes
• Editor: Un editor puede crear, borrar y modificar páginas, y cambiar el sitemap, es decir, puede modificar el orden y crear el menú de navegación. Por herencia tendrá también el siguiente rol.
• Element author: Es el rol más básico de todos ya que no podrá acceder al sitemap editor, solo podrá modificar los contenidos de las páginas actuales pero no podrá crear nuevas secciones, ni modificar el orden de navegación.

 

A parte de los nuevos roles que han aparecido, hemos notado otro cambio importante en la gestión de permisos y ha sido la desaparición de la herencia de grupos. Antes era muy normal tener una estructura anidada de grupos de forma que los permisos dados a los grupos padres se heredaban a los grupos hijos. Ahora esta herencia no la tenemos por lo que debemos tenerlo en cuenta a la hora de pensar nuestra configuración de permisos.

No es un cambio importante ya que tenemos alternativas, pero para los que estabamos acostumbrados a usarlo ha sido un cambio extraño y no avisado por Alkacon.