J3.x

Difference between revisions of "Access Control List Tutorial/nl"

From Joomla! Documentation

(Created page with "Het is ook belangrijk te begrijpen de mogelijkheid om onderliggende groepen te hebben optioneel is. Het scheelt u tijd bij het opzetten van nieuwe groepen. U kunt echter als u...")
(Created page with "===Component Opties & Rechten===")
Line 207: Line 207:
 
Het is ook belangrijk te begrijpen de mogelijkheid om onderliggende groepen te hebben optioneel is. Het scheelt u tijd bij het opzetten van nieuwe groepen. U kunt echter als u dat wilt alle groepen opzetten met Publiek als hoofdgroep en geen rechten overnemen van een bovenliggende groep.
 
Het is ook belangrijk te begrijpen de mogelijkheid om onderliggende groepen te hebben optioneel is. Het scheelt u tijd bij het opzetten van nieuwe groepen. U kunt echter als u dat wilt alle groepen opzetten met Publiek als hoofdgroep en geen rechten overnemen van een bovenliggende groep.
  
===Component Options & Permissions===
+
===Component Opties & Rechten===
  
 
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.
 
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.

Revision as of 07:41, 5 May 2015

Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎eesti • ‎español • ‎français • ‎italiano • ‎português • ‎português do Brasil • ‎Ελληνικά • ‎русский • ‎中文(台灣)‎
Joomla! 
3.x
serie

J3.x:Access Control List/nl

Een gescheiden ACL voor bekijken en doen

Het Joomla ACL systeem kan worden gezien als zijnde verdeeld in twee volledig gescheiden systemen. Eén systeem bepaalt welke dingen op de site gebruikers kunnen zien. Het andere systeem bepaalt welke dingen gebruikers kunnen doen (welke acties een gebruiker kan uitvoeren). Het rechten systeem (ACL) voor elk is anders opgezet.

Bepalen wat gebruikers kunnen zien

De instellingen om te bepalen wat gebruikers kunnen zien is als volgt:

  • Maak een set toegangsniveaus volgens de categorieën en/of combinatie van categorieën waarvan u wilt dat alleen ingelogde gebruikers ze mogen zien. N.B wijs nu nog geen gebruikersgroepen toe aan de nieuwe toegangsniveaus.
  • Maak een gebruikersgroep aan met 'Geregistreerd' als hoofdgroep, voor ieder toegangsniveau. Het gebruiken van dezelfde naam voor de gebruikersgroep als het toegangsniveau zal later verwarring voorkomen.
  • Bewerk uw nieuwe toegangsniveaus en koppel de juiste (nieuwe) gebruikersgroep aan elk toegangsniveau. U kunt ook de Super gebruikersgroep (en/of andere standaard gebruikersgroepen, maar niet de 'Gast' gebruikersgroep) aan al uw nieuwe toegangsniveaus koppelen
  • Wijs ieder item dat gezien moet worden aan één toegangsniveau toe. Items zijn inhouds-items (artikelen, contact, enz.), menu-items, en modules.

Elke keer als een gebruiker een item wil bekijken op een Joomla pagina, controleert het programma als volgt of de gebruiker toegangsrechten heeft tot dit item:

  1. Maakt een lijst met alle toegangsniveaus waar de gebruiker toegang toe heeft, gebaseerd op alle groepen waar de gebruiker toe behoort. Als een groep een hoofdgroep heeft dan worden ook de toegangsniveaus van de hoofdgroep opgenomen in de lijst.
  2. Controleert of het toegangsniveau van het item (artikel, module, menu-item, enz.) in die lijst staat. Zo ja, dan wordt het item getoond aan de gebruiker. Zo nee, dan wordt het item niet getoond.

Let op dat toegangsniveaus apart ingesteld worden voor iedere groep en niet overgenomen worden uit de hoofdgroep van een groep.

Bepalen wat gebruikers kunnen doen

Het systeem voor het instellen wat gebruikers in een gebruikersgroep kunnen doen -- welke acties ze mogen uitvoeren op een bepaald item -- wordt ingesteld via het Rechten-tabblad van de Algemene instellingen en het Rechten-tabblad van het Opties scherm van ieder component. Rechten kunnen ook ingesteld worden op categorie-niveau voor de core-componenten en op artikel niveau voor artikelen.

  • Als u wilt dat ingelogde gebruikers bepaalde categorieën kunnen aanmaken, verwijderen, de status bewerken of hun eigen artikelen bewerken, dan:
    • Maak een gebruikersgroep aan met als hoofdgroep een van de groepen die toegang heeft tot de categorie (of categorieën) waarvan u wilt dat deze de nieuwe gebruikersgroep die kan wijzigen.
    • Geef uw nieuwe gebruikersgroep de juiste toegangsniveaus. Wijzig nu de nodige rechten voor uw nieuwe gebruikersgroep, óf algemeen, óf per categorie/artikel.
      • Bij het aanmaken van een gebruikersgroep is het een goede ervaring een hoofdgroep te selecteren die minder rechten heeft dan noodzakelijk voor de nieuwe groep. Dit is zo omdat het makkelijker is de rechten per component / categorie / artikel, die de extra rechten nodig heeft, te verhogen dan om de rechten te verwijderen van de andere componenten / categorieën / artikelen.
        • (voorbeeld: U heeft 10 categorieën maar u wilt aanmaak-rechten voor slechts 1. Indien u de algemene rechten op 'Maken' zet voor die groep, dan zou u de 'Maak' rechten voor alle categorieën moeten verwijderen. En u zou de 'Maak' rechten voor die groep bij iedere nieuwe categorie die u later toevoegt moeten verwijderen.)
    • Maak alleen een gebruikersgroep met een van de standaard gebruikersgroepen als hoofdgroep aan als geen enkele de exacte rechten heeft die u nodig heeft en u alle categorieën wilt.

Let op dat deze instelling onafhankelijk is van de instellingen voor het bekijken, maar een gebruikersgroep moet aan de juiste toegangsniveaus zijn toegewezen zodat de gebruikers in die groep deze rechten kunnen gebruiken.

Als een gebruiker een specifieke actie wil uitvoeren op een component-item (bijvoorbeeld, bewerken van een artikel) dan zal het systeem (na het controleren of de groep waar de gebruiker in zit toegang heeft) de rechten controleren van deze combinatie van gebruiker, item, en actie. Als het toegestaan is, kan de gebruiker doorgaan. Anders is de actie niet toegestaan.

De rest van deze handleiding beschrijft hoe we bepalen wat gebruikers mogen doen -- welke actie-rechten hebben ze.

Acties, groepen, en overnemen

Het andere deel van ACL is het verlenen van rechten aan gebruikers om acties op objecten uit te voeren.

3.x serie
Groepen en acties De acties die toegestaan zijn door iedere groep worden gedefinieerd door de sitebeheerder.
Bereik van de rechten Rechten kunnen worden ingesteld op meerdere hiërarchische niveaus: Site, component, categorie, object.
Overnemen van rechten Rechten kunnen worden overgenomen van de hoofdgroepen en - categorieën

Hoe rechten werken

Er zijn vier mogelijke rechten voor acties, zoals hieronder beschreven:

  • Niet ingesteld: Standaard ingesteld op "Geweigerd" maar, in tegenstelling tot de geweigerde rechten, kunnen deze rechten worden overschreven door een onderliggende groep of een lager niveau in de rechten-hiërarchie in te stellen op "Toegestaan". Deze rechten gelden alleen voor de Algemene instellingen rechten.
  • Overgenomen: Neemt de waarde van de hoofdgroep of een hoger niveau in de rechten-hiërarchie over. Deze rechten gelden voor alle niveaus behalve het Algemene instellingen niveau.
  • Geweigerd: Weigert deze actie op dit niveau en deze groep. BELANGRIJK: Dit weigert ook deze actie voor alle onderliggende groepen en alle lagere niveaus in de rechten hiërarchie. Het op 'Toegestaan' zetten in een onderliggende groep zal geen effect hebben. De actie zal altijd geweigerd worden voor een lid van een onderliggende groep en elk lager niveau in de rechten-hiërarchie.
  • Toegestaan: Staat deze actie toe voor dit niveau en deze groep en voor lagere niveaus en onderliggende groepen. Dit heeft geen enkel effect als een hogere groep op 'Geweigerd' of 'Toegestaan' staat. Als een hoofdgroep of niveau op 'Geweigerd' staat, dan zullen deze rechten geweigerd worden. Als een hoofdgroep of niveau op 'Toegestaan' staat, dan staan de rechten al op 'Toegestaan'.

Rechten - Hiërarchische niveaus

Actie rechten in versie 2.5 kunnen als volgt in maximaal vier niveaus worden gedefinieerd:

  1. Algemene instellingen: bepalen de standaard rechten voor iedere actie en groep.
  2. Component - Opties->Rechten: kunnen de standaard rechten voor deze component overschrijven (bijvoorbeeld, Artikelen, Menu's, Gebruikers, Advertenties, enz.).
  3. Categorie: kan de standaard rechten van objecten overschrijven in een of meer categorieën. Is van toepassing voor alle componenten met categorieën, waaronder Artikelen, Advertenties, Contacten, Nieuwsfeeds, en Weblinks.
  4. Artikel: Kan de rechten van een speciaal artikel overschrijven. Dit niveau geldt alleen voor artikelen. Andere componenten staan alleen de eerste drie niveaus toe.

Algemene instellingen

Dit wordt bereikt via Systeem → Algemene instellingen → Rechten. Via dit scherm kunt u op het hoogste niveau de rechten voor iedere groep en actie instellen, zoals onderstaande schermafdruk toont.

Screenshot global acl J3 tutorial-nl.png

De opties voor iedere waarde zijn Overgenomen, Toegestaan, of Geweigerd. de kolom met berekende instellingen toont de in werking echte instellingen. Het is óf Niet toegestaan (de standaard), Toegestaan óf Geweigerd.

U werkt met één groep tegelijk door de groep te openen. U wijzigt de rechten in de 'Selecteer nieuwe instelling' drop-down keuzelijst.

Let op dat de berekende instelling niet bijgewerkt wordt tot op de Opslaan-knop in de werkbalk gedrukt wordt. Druk, om te controleren of de instellingen zoals gewenst zijn, op de Opslaan-knop en controleer de kolom berekende instellingen.

Component - Opties->Rechten

Dit is voor iedere component toegankelijk door op het Opties-icoon te klikken in de werkbalk. Dit scherm is gelijk aan het Algemene instellingen scherm hierboven. Door bijvoorbeeld te klikken op het optie werkbalk-icoon in menubeheer worden onderstaande menu-instellingen zichtbaar. Screenshot menu acl J3 tutorial-nl.jpg

De toegang tot Opties is alleen beschikbaar voor leden van de groepen die rechten hebben tot de Instel-actie van iedere component. In bovenstaande voorbeeld heeft de Administrator-groep 'toegestaan' rechten om in te stellen, leden uit deze groep kunnen het scherm dus benaderen.

Categorie

Categorie rechten kunnen via Categoriebeheer bereikt worden: Bewerk artikelcategorie scherm, in een tabblad boven aan het scherm. Dit scherm bevat vijf acties, zoals hieronder getoond.

Screenshot category acl j3 tutorial-nl.png

Op deze schermen werkt u aan de rechten van één gebruikersgroep tegelijk. In bovenstaande voorbeeld bewerken we de rechten van de Administrator groep.

Let er op dat de component-instellingen en - toegangsrechten acties niet op categorie-niveau werken, zodat deze acties er niet in zitten.

Let er ook op dat categorieën hiërarchisch gerangschikt kunnen zijn. Als dat zo is, dan worden actierechten in een hoofdcategorie automatisch overgenomen door een onderliggende categorie. Als u bijvoorbeeld een categorie hiërarchie hebt met Dieren → Huisdieren → Honden, dan is de volledige rechten hiërarchie voor een artikel in de honden categorie als volgt:

  • Algemene instellingen
  • Artikelbeheer → Opties → Rechten
  • Dieren categorie
  • Huisdieren categorie
  • Honden categorie
  • Specifieke artikel

Artikel

Rechten voor een enkel artikel kunnen worden geregeld in Artikelbeheer: Op het Bewerk artikel scherm, via een tabblad op het scherm. Dit scherm heeft drie acties, zoals hieronder zichtbaar is.

J3x acl tutorial article manager article permissions-nl.png

Nogmaals, u bewerkt elke groep door te klikken op de tab van de groep. U kunt dan de rechten wijzigen via de 'Selecteer nieuwe instelling' kolom. Druk, om het resultaat van een wijziging te zien, op de Opslaan-knop om de Berekende instellingen kolom bij te werken.

Let er op dat de instellingen, toegang component, en maak acties niet voorkomen op artikel-niveau, deze acties zitten er hier dus niet in. Rechten om een artikel aan te maken worden op een hoger niveau in de hiërarchie ingesteld.

Toegangsniveaus

De toegangsniveaus in de 3.x serie zijn eenvoudig en flexibel. Onderstaande scherm toont het speciale toegangsniveau.

J3x acl tutorial viewing levels-nl.png

Vink het vakje voor iedere groep die u wilt opnemen op het niveau aan. Het speciale toegangsniveau omvat de Beheerder, Auteur, en de Super gebruikers groepen. Het omvat ook de onderliggende groepen van deze groepen. De Administrator groep is dus opgenomen, aangezien het een onderliggende groep van de Beheerder groep is. De Redacteur en de Hoofdredacteur zijn opgenomen, aangezien ze onderliggende groepen van Auteur zijn. (Merk op dat we alle onderliggende groepen zouden kunnen controleren als we dat wilden en het zou geen kwaad kunnen).

Zodra toegangsniveaus zijn aangemaakt, worden ze op dezelfde manier gebruikt als in versie 1.5. Ieder object op de website heeft een toegangsniveau toegewezen gekregen. Als het niveau 'publiek' is, dan kan iedereen dat object benaderen. Anders kunnen alleen leden van groepen die aan dit toegangsniveau zijn toegewezen dit object benaderen. Toegangsniveaus worden toegewezen aan menu-items en modules. Elke kan slechts aan een toegangsniveau worden toegewezen.

Onderstaande scherm toont bijvoorbeeld het bewerk menu-item scherm met een lijst beschikbare toegangsniveaus.

J3x acl tutorial edit menu item level dropdown-nl.png

Standaard ACL instellingen

Wanneer Joomla! is geïnstalleerd, worden ze op hun initiële standaard waarden gezet. We bespreken deze initiële instellingen als manier om te begrijpen hoe ACL werkt.

Standaard groepen

Versie 3.x geeft de mogelijkheid uw eigen groepen te definiëren. Als u versie 3.x installeert, dan bevat het een set van standaard groepen. Hieronder staan de standaard gebruikersgroepen. (Extra gebruikersgroepen worden geïnstalleerd met de voorbeeld data)

Screenshot usergroupsl acl J3 tutorial-nl.png

De pijlen geven de kind-ouder relatie aan. Als u, zoals hierboven besproken, de rechten voor een hoofdgroep instelt dan worden de rechten automatisch overgenomen door alle onderliggende groepen. De overgenomen en toegestane rechten kunnen overschreven worden voor een onderliggende groep. De geweigerde rechten kunnen niet overschreven worden en zullen voor alle onderliggende groepen altijd geweigerd zijn.

Algemene instellingen

Joomla! versie 2.5 zal met dezelfde vertrouwde beheer-rechten worden geïnstalleerd als versie 1.5. In 2.5 kunt u deze rechten echter eenvoudig aanpassen aan de behoeften van uw site.

Zoals eerder besproken worden de rechten voor iedere actie overgenomen vanuit het bovenliggende niveau in de rechten-hiërarchie en van de hoofdgroep van een groep. Laten we kijken hoe dit werkt. Het hoogste niveau hiervoor is de gehele site. Dit wordt ingesteld op de Systeem->Algemene instellingen->Rechten, zoals hieronder weergegeven.

Screenshot global acl J3 tutorial-nl.png

Het eerste wat opvalt zijn de tien acties: Inloggen website, Inloggen beheer, Offline toegang, Supergebruiker, Toegang tot beheerdersinterface, Maken, Verwijderen, Bewerken, Bewerk status en Bewerk eigen. Dit zijn de acties die een gebruiker kan uitvoeren op een object in Joomla. De specifieke betekenis van iedere actie hangt af van de context. Voor het algemene instellingen scherm worden ze als volgt gedefinieerd:

Inloggen website
Inloggen op de voorkant van de website
Inloggen beheer
Inloggen op het beheergedeelte van de website
Supergebruiker
Verleent de gebruiker "super gebruiker" status. Gebruikers met deze rechten kunnen kunnen alles op de site doen. Alleen gebruikers met deze rechten kunnen de Algemene instellingen (dit scherm) veranderen. Deze rechten kunnen niet beperkt worden. Het is belangrijk te begrijpen dat als een gebruiker lid is van de Super gebruikers groep, iedere ander recht dat toegekend is, niet van belang is. De gebruiker mag elke actie op de site uitvoeren. Toegangsniveaus kunnen echter toegewezen worden om te bepalen wat deze groep op de site ziet. (Uiteraard kan een Super gebruiker toegangsniveaus wijzigen, als ze dat willen, dus toegangsniveaus beperken niet volledig wat een Super gebruiker kan zien.)
Toegang tot beheerdersinterface
Open de component beheer schermen (Gebruikersbeheer, Menubeheer, Artikelbeheer, enz.)
Maken
Het aanmaken van nieuwe objecten (bijvoorbeeld, gebruikers, menu-items, artikelen, weblinks, enz.)
Verwijder
Het verwijderen van bestaande objecten
Bewerken
Het bewerken van bestaande objecten
Bewerk status
Het veranderen van de status van een object (Publiceren Depubliceren, Archiveren, en naar de prullenbak verhuizen)
Bewerk eigen
Bewerk objecten die u zelf heeft aangemaakt.

Iedere groep op de site heeft z'n eigen schuifbalk, die geopend wordt door op de groepsnaam te klikken. In dit geval (met de voorbeelddata geïnstalleerd), hebben we de 7 standaard groepen die we in versie 1.5 hadden plus twee groepen. Houd er rekening mee dat we op ieder moment de rechten kunnen veranderen om die te latten werken zoals we dat willen. Laten we kijken hoe het werkt.

  • Publiek heeft alles staan op "Niet ingesteld", zoals hieronder weergegeven.
    Screenshot global acl public J3 tutorial-nl.png
    • Dit kan een beetje verwarrend zijn. In principe is, "Niet ingesteld" hetzelfde als "Overgenomen". Omdat Publiek de bovenste groep is en omdat de Algemene instellingen het top niveau van de componenten hiërarchie is, is er niets om vanaf over te nemen. "Niet ingesteld" wordt dus gebruikt in plaats van "Overgenomen".
    • De standaard in dit geval is geen rechten. Dus, zoals verwacht, heeft de Publiek groep geen speciale rechten. Het is ook belangrijk dat, aangezien er niets op Geweigerd staat, alle rechten overschreven kunnen worden in onderliggende groepen of door lagere niveaus in de rechten hiërarchie.
  • Gast is een 'onderliggende' groep van de Publiek groep en heeft alles staan op 'Overgenomen'
    Screenshot global acl guest J3 tutorial-nl.png
    • Dit is de standaard 'Gast gebruikersgroep' in de Gebruikersbeheer instellingen en de groep waar (niet-ingelogde) gebruikers op uw site in worden geplaatst.
  • Beheerder is een "onderliggende" groep van de Publiek groep. Het heeft Toegestaan rechten op alles behalve Toegang tot beheerdersinterface en Supergebruiker. Een lid van deze groep kan dus alles op de website en het beheergedeelte van de site doen behalve het wijzigen van de Algemene instellingen en Beheerders instellingen.
    Screenshot global acl manager J3 tutorial-nl.png
  • Administrator groepsleden nemen alle Beheerder rechten over en mogen ook toegang tot de beheerdersinterface. Leden van deze groep hebben dus standaard toegang tot het beheerdersinterface van iedere component.
    Screenshot global acl administrator J3 tutorial-nl.png
  • Geregistreerd is hetzelfde als Publiek behalve de Toegestaan rechten op Inloggen website actie. Dit betekent dat leden van de Geregistreerd groep kunnen inloggen op de website. Omdat standaard rechten overgenomen worden betekent dit dat, behalve als een onderliggende groep deze rechten overschrijft, alle onderliggende groepen van de Geregistreerd groep ook kunnen inloggen.
    Screenshot global acl registered J3 tutorial-nl.png
  • Auteur is een onderliggende groep van de Geregistreerd groep en neemt de rechten over en voegt ook de Maken en Bewerk eigen acties toe. Aangezien Auteur, Redacteur en Hoofdredacteur geen beheergedeelte rechten hebben, bespreken we ze hieronder, als we de website rechten bespreken.
    Screenshot global acl author J3 tutorial-nl.png
  • Redacteur is afgeleid van de Auteur groep en voegt de Bewerk rechten toe.
    Screenshot global acl editor J3 tutorial-nl.png
  • Redacteur is afgeleid van de Auteur en voegt de Bewerk status rechten toe.
    Screenshot global acl publisher J3 tutorial-nl.png
  • Winkeliers is een voorbeeldgroep die wordt geïnstalleerd als de voorbeelddata geïnstalleerd worden. Het is een afgeleide groep van Auteur.
  • Klant groep is een voorbeeldgroep die geïnstalleerd is als de voorbeelddata geïnstalleerd zijn. Het is een afgeleide groep van Geregistreerd.
  • Super gebruikers groep heeft de Toegestaan rechten voor de Supergebruiker actie. Daarom hebben leden van deze groep supergebruikers rechten op de hele site. Ze zijn de enige gebruikers die toegang hebben tot het Algemene instellingen scherm en de waarden bewerken. Gebruikers met rechten op Supergebruikers acties hebben enkele speciale kenmerken:
  • Als een gebruiker Supergebruiker rechten heeft, zijn er geen andere rechten voor deze gebruiker van belang. De gebruiker mag alles op de site.
  • Alleen Super gebruikers kunnen andere Super gebruikers of groepen aanmaken, bewerken of verwijderen.

Er zijn twee heel belangrijke punten om te begrijpen op dit scherm. De eerste is te zien hoe rechten overgenomen kunnen worden van de hoofdgroep. De tweede is hoe u de standaard rechten kunt beheren per groep en per actie.

Dit biedt veel flexibiliteit. Als u bijvoorbeeld leveranciers van winkels de mogelijkheid wilt geven in het beheergedeelte in te loggen, verander dan hun Toegang tot beheerdersinterface in "Toegstaan". Als u niet wilt dat leden van de Beheerder groep objecten kunnen verwijderen of hun status kunnen veranderen, dan moet u de rechten in deze kolommen veranderen in Overgenomen (of Geweigerd).

Het is ook belangrijk te begrijpen de mogelijkheid om onderliggende groepen te hebben optioneel is. Het scheelt u tijd bij het opzetten van nieuwe groepen. U kunt echter als u dat wilt alle groepen opzetten met Publiek als hoofdgroep en geen rechten overnemen van een bovenliggende groep.

Component Opties & Rechten

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:

Screenshot acl tutorial 20110111-09-en.png
Screenshot acl tutorial 20110111-10-en.png

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.

Front End Permissions

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.

Screenshot acl tutorial 20110111-11a-en.png

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.

Screenshot acl tutorial 20110111-12a-en.png

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.

Screenshot acl tutorial 20110112-07-en.png

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.

Screenshot acl tutorial 20110112-08-en.png

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.

Screenshot acl tutorial 20110112-09-en.png

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.

Article Manager & Actions Diagram

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

Screenshot acl tutorial 20110111-16-en.png
  • 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.

Allowing Guest-Only Access to Menu Items and Modules

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.

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

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,

Screenshot acl tutorial 20110112-05-en.png

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.

Using Permission and Group Levels Together

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.

Acl example diagram1 20091018-en.png

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.

Acl example diagram2 20091018-en.png

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.

ACL Action Permission Examples

Here are some examples of how you might set up the ACL for some specific situations.

Back-end Article Administrator

Problem:

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.

Solution:

  1. Create a new group called Article Administrator and make its parent group Public, as shown below.
    Screenshot acl tutorial 20110112-10-en.png
    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.)
    Screenshot acl tutorial 20110112-11-en.png
    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.
    Screenshot acl tutorial 20110112-12-en.png
    After you save, the Calculated Permissions should show as shown below.
    Screenshot acl tutorial 20110112-13-en.png
    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.
    Screenshot acl tutorial 20110112-14-en.png
    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.

Screenshot acl tutorial 20110112-15-en.png

ACL View Access Levels Examples

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.

Hierarchical Example

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.

Team Security Example

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


Hybrid Example

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