J3.x:Access Control List Tutorial/es

Joomla! 

3.x

series

ACL independiente para Ver y Hacer

El sistema ACL de Joomla puede ser pensado como dividido en dos sistemas completamente independientes. Uno de los sistema controla que cosas pueden ver los usuarios en el sitio. El otro controla que cosas pueden hacer los usuarios (que acciones puede tomar un usuario). La ACL para cada uno es diferente.

Controlar Que Pueden Ver los Usuarios

La configuración para controlar que pueden ver los usuarios se hace de la siguiente manera:

• Crea un conjunto de Niveles de Acceso de acuerdo a las Categorías y/o la combinación de categorías que desees y que sólo los usuarios registrados podrán ver. N.B. no asignes grupos de usuarios a los nuevos Niveles de Acceso en este momento.

• Crea un Grupo de usuarios, con 'Registrado' como los padre, para cada Nivel de Acceso. Utilizando los mismos nombres tanto para los Grupos de usuarios como los Niveles de Acceso para evitar confusiones en el futuro.

• Edita tus nuevos Niveles de Acceso y asigna el (nuevo) Grupo de usuarios que corresponda a cada uno de ellos. También puedes desear asignar el Grupo de Super Usuarios (y/o otros Grupos de Usuarios de forma predetermianda, pero no el Grupo de Usuarios 'Invitados') a todos los nuevos Niveles de Acceso

• Asigna a cada ítem a ser visto un Nivel de Acceso. Los ítems incluyen elementos de contenido (artículos, contactos, etc), elementos de menú y módulos.

Cada vez que un usuario se acerca a ver un elemento en una página de Joomla!, el programa comprueba si el usuario tiene acceso al ítem, de la siguiente manera:

1. Crea una lista de todos los Niveles de Acceso a los que tiene acceso el Usuario, basado en todos los Grupos a los que pertenece el Usuario. También, si un grupo tiene un grupo padre, los niveles de acceso para el grupo padre también se incluyen a la lista.
2. Comprueba si el Nivel de Acceso para el em (artículo, módulo, elemento del menú, y así sucesivamente) está en la lista. Si esta, entonces el ítem se mostrará al usuario. Si no esta, entonces el elemento no se muestra.

Ten en cuenta que los Niveles de Acceso se establecen por separado para cada Grupo y no se heredan de un grupo padre del grupo.

Controlar Que Pueden Hacer los Usuarios

El sistema de configuración sobre lo que los usuarios en un Grupo de usuarios pueden hacer (qué acciones se pueden tomar en un determinado punto) es configurado con los Permisos de la pestaña Configuración Global y la pestaña de Permisos de la pantalla de Opciones de cada componente. Los permisos también se pueden configurar en el nivel de Categoría de componentes principales y en el nivel de Artículo para los artículos.

• Si deseas que los usuarios conectados puedan Crear, Eliminar, Editar Estado o Editar sus Propia ítem, para Categorías específicas entonces:
  • Crea un Grupo de Usuarios con uno de los Grupos de Usuarios, que tiene Acceso a la Categoría (o Categorías), como Padre; este nuevo Grupo de Usuarios será el que vamos a modificar.
  • Asigna a tu nuevo Grupo de usuarios el Nivel de Acceso adecuado(s). A continuación, cambia los permisos necesarios a tu nuevo Grupo de Usuarios, ya sea a nivel global o por Categoría/Artículo.
    • Esto se debe a que es más fácil elevar los permisos por Componente/Categoría/Artículo donde se necesitan permisos adicionales, que eliminar los permisos de los otros Componentes/Categorías/Artículos.
      • (ejemplo: Tienes 10 Categorías, pero deseas dar permiso Crear para 1 sola. Si estableces permisos Globales para Permitir Crear a un grupo tendrás que quitar el permiso Crear para todas las demás categorías. Y tendrás que quitar el permiso Crear del grupo para cualquier nueva Categoría que agregues a futuro.)
  • Sólo crea un Grupo de Usuarios con uno de los Grupos de Usuarios predeterminado como padre, si ninguno de ellos tiene los permisos exactos que necesitas y deseas para todas las Categorías

Ten en cuenta que esta configuración es independiente de la configuración para la visualización, pero es necesario asignar a un Grupo de Usuarios el(los) Nivel(es) de acceso adecuado(s) para que el usuario de ese Grupo para contar con esos Permisos.

Cuando un usuario quiere iniciar una acción específica sobre un ítem del componente (por ejemplo, editar un artículo), el sistema (después de comprobar que el Grupo del usuario tiene acceso) comprueba el permiso para esta combinación de usuario, ítem y acción. Si está permitido, el usuario puede proceder. De lo contrario, la acción no será permitida.

El resto de este tutorial explica cómo podemos controlar lo que los usuarios pueden hacer --que permisos de acción tienen.

Acciones, Grupos y Herencia

El otro lado de la ACL es la concesión de permisos a los usuarios para tomar acciones sobre los objetos.

	series 3.x
Grupos y Acciones	Las acciones permitidas a cada grupo son definidas por el administrador del sitio.
Alcance del permiso	Se pueden establecer permisos en varios niveles de jerarquía: Sitio, Componente, Categoría, Objeto.
Herencia de Permisos	Los permisos pueden ser heredados de los Grupos y Categorías padres

Cómo Funcionan los Permisos

Hay cuatro permisos posibles para las acciones, como se indica a continuación:

• Sin establecer: de forma predeterminada es "negar" pero, a diferencia del permiso Denegar, este permiso puede ser reemplazado por la configuración "Permitir" a un grupo hijo o de un nivel inferior en la jerarquía de permisos. Este permiso sólo se aplica a la Configuración Global de los permisos.
• Heredar: Hereda el valor de un Grupo padre o de un nivel más alto en la jerarquía de permisos. Este permiso se aplica a todos los niveles, excepto al nivel Global de Configuración.
• Denegar: Niega esta acción para este nivel y grupo. IMPORTANTE: Esto también niega esta acción para todos los grupos hijos y todos los niveles inferiores en la jerarquía de permisos. Poner Permitir a un grupo hijo o de un nivel inferior no tendrá ningún efecto. La acción siempre será negado para cualquier miembro del grupo hijo y cualquier nivel inferior en la jerarquía de permisos.
• Permitir: Permite esta acción para este nivel y grupo y para los niveles más bajos y grupos secundarios. Esto no tiene ningún efecto si un grupo superior o nivel se establece como Permitir o Denegar. Si un grupo o nivel superior se ajusta a Denegar, entonces este permiso siempre será denegado. Si un grupo o nivel superior está configurado como Permitir, entonces este permiso ya estará permitido.

Jerarquía de Niveles de Permisos

Los permisos de acción en la versión 2.5 se pueden definir hasta por cuatro niveles, de la siguiente manera:

1. Configuración Global: determina los permisos predeterminados para cada acción y grupo.
2. Componente Opciones->Permisos': puede anular los permisos predeterminados para este componente (por ejemplo, Artículos, Menús, los Usuarios, Banners, etc).
3. Categoría: Puede anular los permisos predeterminados de los objetos en una o más categorías. Se aplica a todos los componentes con categorías, incluyendo Artículos, Banners, Contactos, fuentes de Noticias y Enlaces web.
4. Artículo: Puede anular los permisos de un artículo específico. Este nivel sólo se aplica a los artículos. Otros componentes sólo se permiten los tres primeros niveles.

Configuración Global

A la que se accede desde Sistema (Administrador) → Configuración Global → Permisos. Esta pantalla te permite establecer el nivel superior de permisos para cada grupo por cada acción, como se muestra en la siguiente captura de pantalla.

Las opciones para cada valor son: Heredado, Permitido o Denegado. La columna Configuración calculada muestra la configuración aplicada. No Permitido (valor predeterminado), Permitido o Denegado.

Trabaja en un Grupo a la vez abriendo el control deslizante para ese grupo. Cambia los permisos en los cuadros de lista desplegable de la columna Seleccionar la nueva configuración.

Ten en cuenta quela columna de Configuración calculada se actualizará hasta que pulses el botón Guardar en la barra de herramientas. Para comprobar que la configuración es la deseas, presiona el botón Guardar y comprobar el valor de la columna Configuración calculada.

Componente: Opciones->Permisos

A los que se accede para cada componente haciendo clic en el icono Opciones en la barra de herramientas. Esta pantalla es similar a la pantalla de Configuración Global anterior. Por ejemplo, haciendo clic en el icono Opciones de la barra de herramientas en el Gestor de Menús muestra la Configuración de los Menús que se ve a continuación.

El acceso a las Opciones sólo está disponible para los miembros de los grupos que tienen permiso para Configurar una acción para cada componente. En el ejemplo anterior, el Administrador del grupo ha colocado como Permitido el permiso para la opción de Configuración, de forma tal que los miembros de este grupo pueden acceder a esta pantalla.

Categoría

Los permisos de Categorías tienen acceso en el Gestor de Categorías: A la pantalla Editar Categoría, se accede por un botón en la parte superior de la pantalla y luego en la pestaña Permisos. Esta pantalla tiene cinco permisos, como se muestra a continuación.

En estas pantallas, se trabaja en los permisos para un Grupo de usuarios por vez. En el ejemplo anterior, estamos editando los permisos para el grupo Administrador.

Ten en cuenta que Configurar y Acceso a las acciones de Componentes no se aplican a nivel de la categoría, por lo que esas acciones no están incluidas.

Ten en cuenta también que las Categorías pueden ser organizadas de forma jerárquica. Si es así, entonces los permisos a una acción en la categoría principal se heredan automáticamente por una categoría hija. Por ejemplo, si tenías unas categorías jerarquizadas Animales → Mascotas → Perros, entonces los niveles de permisos completos jerarquizados para un artículo en la categoría Perros sería como sigue:

• Configuración Global
  • Gestor de Artículos → Opciones → Permiso
    • Categoría Animales
      • Categoría Mascotas
        • Categoría Perros
          • Artículo específico

Artículo

Los permisos para un solo artículo son accesibles desde el Gestor de artículos: A la pantalla Editar Artículo, se accede por un botón en la partes superior de la pantalla y luego en la pestaña Permisos. Esta pantalla tiene tres acciones, como se muestra a continuación.

De nuevo, se edita cada grupo haciendo clic sobre él para abrir el control deslizante para ese grupo. A continuación, se puede cambiar los permisos en la columna Seleccionar la nueva configuración. Para ver el efecto de cualquier cambio, pulsa el botón Guardar para actualizar la columna Configuración Calculada.

Ten en cuenta que las acciones Configurar, Acceso al Componente y Crear no se aplican a nivel de artículo, por lo que estas acciones no están incluidas. El permiso para crear un artículo se establece en uno de los niveles más altos en la jerarquía.

Niveles de Acceso

Los Niveles de acceso en las series 3.x son simples y flexibles. La pantalla siguiente muestra el Nivel de Acceso Especial.

Simplemente marca la casilla para cada grupo que se deseas incluir en ese nivel. El Nivel de Acceso Especial incluye a los grupos Gestor, Autor, y Super Usuarios. También incluye grupos hijos de esos grupos. Así, el grupo Administrador es incluido, ya que es hijo del grupo Gestores. Los grupos Editor, Supervisor(Publisher) y Proveedores son incluidos, ya que son hijos del grupo Autor. (Ten en cuenta que podríamos comprobar todos los grupos hijos si quisiéramos y cosa que no estaría de más).

Una vez que los Niveles de Acceso se crean, se utilizan de la misma manera como en la versión 1.5. A cada objeto del lado cliente se le asigna un Nivel de Acceso. Si el nivel es Público, cualquier persona puede tener acceso a ese objeto. De lo contrario, sólo los miembros de los grupos asignados a ese nivel de acceso puede tener acceso a ese objeto. Los niveles de acceso se asignan a los Ítems del Menú y a los Módulos. Cada uno sólo puede tener asignado un nivel de acceso.

Por ejemplo, la imagen de abajo muestra el la pantalla del Ítem de Menú Edición, con la lista de niveles de acceso disponibles.

Instalación predeterminada de ACL

Cuando Joomla! está instalado, esto se establece en sus ajustes predeterminados iniciales. Vamos a discutir estos valores iniciales, como una manera de entender cómo trabaja ACL.

Grupos Predeterminados

La versión 3.x te permite definir tus propios Grupos. Al instalar la versión 3.x, se incluyen un conjunto predeterminado de grupos, que se muestran a continuación y son la base de grupos de usuarios predeterminados. (Otros grupos de usuarios predeterminados se instalan con los datos de ejemplo)

Las flechas indican las relaciones padre-hijo. Como se mencionó anteriormente, cuando se establece un permiso para que un grupo padre, este permiso se hereda automáticamente en todos los grupos hijos. Los permisos Heredado y Permitido pueden ser anulados para un grupo hijo. El permiso Denegado no puede ser reemplazado y siempre va a denegar una acción para todos los grupos hijos.

Configuración Global

La versión 2.5 de Joomla! se instala con los mismos permisos del lado servidor, ya conocidos, como en la versión 1.5. Sin embargo, en 2.5, puedes fácilmente cambiar estos permisos para satisfacer las necesidades de tu sitio.

Como se discutió anteriormente, los permisos para cada acción se heredan desde el nivel superior en la jerarquía de permisos y de un grupo de padre del grupo. Vamos a ver cómo funciona esto. El nivel superior de esto es para toda la web. Esto se configura en Sitio->Configuración Global->Permisos, como se muestra a continuación.

La primera cosa a tener en cuenta son las nueve Acciones: Inicio de Sesión en el Sitio, inicio de Sesión en el Administrador, Super Admin, Acceso a un Componente, Crear, Borrar, Editar, Editar Estado y Edición Propia. Estas son las acciones que puede realizar un usuario en un objeto en Joomla!. El significado específico de cada acción depende del contexto. Para la pantalla de Configuración Global, se definen como sigue:

Inicio de Sesión en el sitio

Inicio de Sesión en el lado cliente del sitio

Inicio de Sesión en el Administrador

Inicio Sesión en el lado servidor del sitio

Súper Administrador

Otorga al usuario estado de "super usuario". Los usuarios con este permiso puede hacer cualquier cosa en el sitio. Sólo los usuarios con este permiso puede cambiar las opciones de Configuración Global (esta pantalla). Estos permisos no pueden ser restringidos. Es importante entender que, si un usuario es miembro del grupo Súper Administrador, cualquier otro permiso asignado a este usuario es irrelevante. El usuario puede realizar cualquier acción en el sitio. Sin embargo, los Niveles de Acceso todavía pueden ser asignado para controlar lo que este grupo puede ver en el sitio. (Obviamente, un usuario Súper Administrador puede cambiar los Niveles de Acceso si lo desea, por lo que los Niveles de Acceso no restringe totalmente lo que puede ver un usuario Súper Administrador).

Acceso a un Componente

Abrir la pantalla del gestor de componentes (Gestor de Usuarios, Gestor de Menús, Gestor de Artículos y así sucesivamente)

Crear

Creación de nuevos objetos (por ejemplo, usuarios, ítems del menú, artículos, enlaces web, etc)

Eliminar

Eliminación de los objetos existentes

Editar

Edición de objetos existentes

Editar Estado

Cambio del estado del objeto (Publicar, Despublicar, Archivo, y la Basura)

Edición Propia

Edición de los objetos que ha creado.

Cada Grupo en el sitio tiene su propio control deslizante que se abre haciendo clic en el nombre del grupo. En este caso (con los datos de ejemplo instalados), tenemos el estándar de 7 grupos que teníamos en la versión 1.5, además de dos grupos adicionales llamado "Proveedores de la Tienda" y "Grupo Clientes". Nota que nuestros grupos tienen establecidos los mismos permisos que los que tenían en la versión 1.5. Ten en cuenta que podemos cambiar cualquiera de estos permisos para lograr que la seguridad trabaje de la manera que queremos. Vamos a ir a través de esto para ver cómo funciona.

• Público tiene todo configurado como "No establecido", como se muestra a continuación.
  
  • Esto puede ser un poco confuso. Básicamente, "No Establecido" es lo mismo que "Heredado". Porque Público es nuestro grupo de nivel superior y debido a que en la Configuración Global es el nivel superior en la jerarquía de componentes, no hay nada que heredar. Por lo que "No Establecido" se utiliza en lugar de "Heredar".
  • El valor predeterminado en este caso es que no hay permisos. Así que, como era de esperar, el grupo Público no tiene permisos especiales. También, es importante destacar que, dado que nada esta Negado todos estos permisos se puede reemplazar por los de grupos hijos o de niveles inferiores en la jerarquía de permisos.

• Invitado es un grupo 'hijo del grupo Público, tiene todo configurado como 'Heredado'
  
  • Este el 'Grupo de Usuarios Invitados' predeterminado en las opciones del Gestor de Usuarios y el Grupo de los visitantes (no conectado) a tu sitio están colocados aquí.

• Gestor es un grupo 'hijo' del grupo Público. Tiene permisos Permitido para todo, excepto el de Acceso a Componentes y de Súper Administrador. Por lo que un miembro de este grupo puede hacer todo en la parte cliente y en la parte servidor del sitio, excepto el cambiar los Permisos Globales y las Opciones del Componente.
  

• Administrador los miembros del grupo heredan todos los permisos del grupo Gestor y también tienen Permitido el Acceso a los Componentes. Así que los miembros de este grupo de forma predeterminada puede acceder a las pantallas de Opciones para cada componente.
  

• Registrado es lo mismo que Público excepto por el permiso Permitido para la acción Inicio de Sesión en el Sitio. Esto significa que los miembros del grupo Registrado puede ingresar al sitio. De forma predeterminada los permisos se heredan, esto significa que, a menos que un grupo hijo anule estos permisos, todos los grupos hijo del grupo Registrado serán capaz de iniciar sesión.
  

• Autor es un grupo hijo del grupo Registrado y hereda sus permisos y se le suman también Crear y Editar Propios. Ya que Autor, Editor y Supervisor (Publisher) no tienen permisos para acceder al lado servidor, vamos a discutir más adelante sobre ellos, cuando hablemos de los permisos del lado cliente.
  

• Editor es un grupo hijo del grupo Autores y se le agrega el permiso de Edición.
  

• Supervisor (Publisher) es un grupo hijo de Editor y se le agrega el permiso de Edición de Estado.
  

• Proveedores de la Tienda es un grupo de ejemplo que se instala al instalar los datos de ejemplo. Es un grupo hijo de Autor.

• Grupo clientes es un ejemplo de grupo que se instala al instalar los datos de ejemplo. Es un niño del grupo de Registrados.

• Super Users group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:

• If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
• Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

Componente: Opciones y Permisos

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

Permisos Lado Cliente

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.

Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.

Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.

This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.

So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.

So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

Gestor de Artículos y Diagrama de Acciones

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

• Configure allows you to view and change the Options for the component.
• Access Component allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
• Create allows you to add new articles.
• Delete allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
• Edit allows you to edit existing articles.
• Edit State allows to you Publish, Unpublish, Archive, or Trash articles.
• Edit Own is the same as Edit except that it only applies to articles written by you.

Permitir a los Invitados Sólo el Acceso a los Ítems del Menú y Módulos

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature. (N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install

1. Create a new user group called Guest. Make it a child of the Public group as shown below.
   
2. Create a new access level called Guest and grant only the Guest group access to this level, as shown below.
   
3. Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,

this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

N.B. Login/logout in front end (for changing data in session) to see the change.

Usar juntos Niveles de Permisos y Grupos

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

• both groups can create new articles only in the History Assignments category.

• only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

Ejemplos de Permisos en Acciones ACL

Aquí hay algunos ejemplos de cómo puedes configurar las ACL para algunas situaciones específicas.

Lado Servidor, Administrador de Artículos

Problema:

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

Solución:

1. Create a new group called Article Administrator and make its parent group Public, as shown below.
   
   Because its parent group is Public, it won't have any permissions by default.
2. In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)
   
   By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
3. In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.
   
   After you save, the Calculated Permissions should show as shown below.
   
   Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
4. In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.
   
   All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.

Ejemplos de Niveles de Acceso ACL a las Vistas

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

Ejemplo de Jerarquía

In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

User	Group	Access Levels
C1, C2, C3	Classified	Classified
S1, S2, S3	Secret	Classified, Secret
TS1, TS2, TS3	Top Secret	Classified, Secret, Top Secret

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

Ejemplo de Equipo de Seguridad

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

User	Description	Group	Access Levels
U1	Team 1 member	T1	T1
U2	Team 2 member	T2	T2
U3	Team 3 member	T3	T3
U1-2	Member of teams 1 and 2	T1, T2	T1, T2
U1-3	Member of teams 1 and 3	T1, T3	T1, T3
U1-2-3	Member of teams 1,2, and 3	T1,T2, T3	T1, T2, T3

Ejemplo Híbrido

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

Access Level	Description	Groups
Manager	Non-team manager documents	Manager
Staff	Non-team staff documents	Manager, Staff
Team1	Sensitive Team1 documents (no access outside team)	Team1
Team1-Manager	Team1 documents that can be accessed by all managers	Team1, Manager
Team2	Sensitive Team2 documents (no access outside team)	Team2
Team2-Manager	Team2 documents that can be accessed by all managers	Team2, Manager

Then, users could be assigned to groups as follows:

User Type	Group
Manager on no teams	Manager
Staff on no teams	Staff
Manager on team 1	Manager, Team1
Staff on team 1	Staff, Team1
Manager on teams 1 and 2	Manager, Team1, Team2
Staff on teams 1 and 2	Staff, Team1, Team2