Dieses Tutorial gibt meinen Vortrag auf den Joomladays 2011 am 2./3. September in Hamburg wider. Die Power Point Folien sind hier direkt eingearbeitet und der freie Vortrag als Manuskript beigelegt. Es handelt sich hier um eine Einführung in das Rechtesystem. Kleinere Beispiele erklären die angesprochenen Möglichkeiten.

Im Downloadcenter von time4mambo steht dieses Tutorial als PDF zum download bereit.

Der Vortrag liegt auch als Video vor: http://vimeo.com/30361291

Einführung

Lange haben wir darauf gewartet und seit Joomla!1.6 haben wir endlich eine erweiterte Rechteverwaltung. Mussten wir uns in Joomla!1.5 mit meist schwer zu handhaben Komponenten herumplagen, haben wir nun eine Rechteverwaltung, die sehr viele Möglichkeiten bietet und fast alles abdeckt.

Jedoch ist auch diese "hauseigene" Rechteverwaltung nicht ganz einfach zu durchschauen und man muss sich ein wenig Zeit für sie nehmen, um sie zu erfassen und in seiner Gänze zu verstehen.

Es gibt im Wesentlichen zunächst drei Bereiche:

• Benutzergruppe
• Zugriffsebene
• Konfiguration: Berechtigungen

Die Benutzergruppen und Zugriffsebenen erreichen wir über das Benutzermenü:

Wobei man sich hier in Erinnerung rufen sollte, wo die Zugriffsebenen eingestellt werden und wo die Benutzergruppen relevant sind. Man kann dann bereits den Umfang nur dieser ersten beiden Bereiche bereits erahnen.

• Eine Zugriffsebene kann mehreren Benutzergruppen zugeordnet werden

In der Folie sehen wir ein Beispiel mit der Zugriffsebene Spezial.
Beiträge, etc. die die Zugriffsebene Spezial erhalten, können von Managern, Autoren und Super Benutzern eingesehen und benutzt werden.

Eine Zugriffsebene kann also von verschiedenen Benutzergruppen aufgerufen werden
Ein Beispiel sieht man mit dem Recht Spezial, dass für mehrere Benutzergruppen gilt.

• Zusätzlich kann eine Benutzergruppe auch mehreren Zugriffsebenen zugeordnet sein

Als Beispiel hier die Zuordnung für die Benutzergruppe Manager, die sowohl die Zugriffsebene Registriert, als auch Spezial sehen kann:

Aus diesen sehr einfachen Zuordnungen können bereits eine Fülle von unterschiedlichen Szenarien abgeleitet werden.

Beispiel - Multiuser

In Joomla 1.5 musste ich einmal ein Projekt einstellen, weil  es nicht möglich war auf verschiedene  Komponenten mit mehreren unterschiedlichen Benutzergruppen gleichzeitig zugreifen zu können und zusätzlich verschiedenen Benutzergruppen unterschiedliche Zugriffsebenen zu zuordnen. Also Multiuserrechte zu zuweisen. Unmöglich wurde es u.a. bei einem Forum. Egal, welches Forum ich damals ausprobierte, ich konnte lediglich mittels Menüführung auf Forenkategorien zugreifen - ich konnte jedoch die Sichtbarkeit der Foren nicht direkt über das Forum steuern.

Was in Joomla 1.5 zur Unmöglichkeit geriet, ist in Joomla 1.7 ein ganz einfaches Szenarium:

Der Einfachheit halber mache ich das Beispiel nur mit zwei Benutzergruppen

• Benutzergruppe: Tischler
• Benutzergruppe: Elektriker

Da wir im Forum nur registrierte Benutzer schreiben lassen möchten, ordne ich meine beiden neuen Benutzergruppen der übergeordneten Gruppe "Registriert" zu. Damit werden automatisch alle Einstellungen, die für die Benutzergruppe Registriert vorgegeben sind, übernommen.

Neben den beiden Benutzergruppen brauche ich noch eine Zugangsebene für die jeweilige Gruppe und eine Zugriffsebene, auf die beide neuen Gruppen zugreifen können:

Man muss bei den jeweiligen Titeln im Übrigen nicht bei einsilbigen Wörtern bleiben - man kann also auch aussagekräftige Bezeichnungen, die aus mehreren Wörtern bestehen, verwenden.

Mit diesen drei neuen Zugriffsebenen kann ich nun beispielsweise Menüverweise nur für Tischler und nur für Elektriker erstellen, aber auch Menüverweise mit Informationen, die für beide Berufsgruppen, bzw. Benutzergruppen, gelten.

Eine sehr schöne Möglichkeit bietet das Kunena-Forum:

Bei Kunena kann man auswählen, ob man eine Zugriffsebene oder eine Benutzergruppe zuordnen möchte. Der Vorteil hier wäre, dass ich mir zwei Zugriffsebenen sparen könnte (Zugriff Tischler und Zugriff Elektriker), sofern ich die Zugriffsebenen nur für das Forum bräuchte.

Außerdem kann ich das ganze so auch recht übersichtlich gestalten. In der Forenübersicht wird denn genau angezeigt, was eingestellt wurde:

Diese doch recht überschaubaren Beispiele zeigen bereits eine Fülle von Möglichkeiten auf, die sich mit der neuen Rechteverwaltung recht einfach umsetzen lässt.

Aber man kann auch die Berechtigungen der einzelnen Benutzergruppen einstellen und zuordnen, was denn sehr umfangreiche Szenarien zulässt, gleichzeitig aber nicht immer so ganz einfach zu durchschauen ist.

Konfiguration: Berechtigungen

Wechseln wir nun in die Konfiguration und dort in den Tab Berechtigungen. Hier ist quasi das Herzstück der Rechtevergabe.

Hier sehen wir auf einen Blick, welche Benutzergruppe welche Rechte hat. Wer schreiben oder nur lesen darf, wer veröffentlichen, sich einloggen und vielerlei mehr machen kann.

Dabei ist die Hierarchie auch wichtig. Die untergeordnete Gruppe erbt die Einstellungen der übergeordneten Gruppe.

Beispiel:

• Die Gruppe der Registrierten darf sich auf der Seite anmelden - mehr nicht.
• Der Autor liegt eine Ebene unter Registriert und erbt das Anmelden dürfen und erhält zusätzlich noch die Erlaubnis Erstellen und Eigene Inhalte bearbeiten zu dürfen.
• Der Editor liegt n der Hierarchieebene unter dem Autoren und erbt somit alle Rechte des Registrierten und des Autors

Somit kann man also direkt beim Anlegen einer neuen Benutzergruppe bereits eine gewisse Vorauswahl über die Berechtigungen treffen.

Man kann aber auch diese Hierarchieebene beeinflussen, in dem man Berechtigungen explizit erlauben, sperren oder eben vererben kann. Mit dieser Einstellung bin ich also sehr frei in der Hierarchie und kann sehr gezielt  Berechtigungen zuweisen. Auch wenn die Hierarchieebene es normalerweise erlauben würde, dass eine zuvor zugewiesene Berechtigung durch die Vererbung auch hier erlaubt wäre, kann diese dennoch explizit gesperrt werden.

Es gibt also kein starres Gerüst, sondern mannigfaltige Möglichkeiten, den einzelnen Benutzergruppen individuelle Berechtigungen zu zuweisen.

Betrachten wir uns aber nun die Berechtigungen im Einzelnen:

Im Großen und Ganzen kann man die Berechtigungen in zwei große Blöcke teilen:

• Backend
• Frontend

Das ist zwar nicht ganz richtig, weil die Offline Anmeldung genau genommen nichts mit dem Backend zu tun hat, andererseits aber durchaus als "Sonderrecht" betrachtet werden darf.

Als erstes haben wir die Seiten Anmeldung. Damit kann eingestellt werden, welche Benutzergruppe das Recht bekommt, sich auf der Seite zu registrieren und einzuloggen.  Dabei muss man nun aber der Joomla-Logik ein wenig folgen. Die besagt nämlich nicht etwa, dass die Benutzergruppe Namens Öffentlich sich einloggen darf, sondern die Gruppe Registriert. Aus unserer Sicht wäre es ja umgekehrt logischer. Ein öffentlicher darf sich anmelden. Ist er das dann steigt er in die Gruppe Registriert auf. Joomla ist da aber gnadenlos und teilt mit, welche Gruppe zu den angemeldeten gehört. So ist es nicht verwunderlich, dass außer der öffentlichen Gruppe alle anderen sich anmelden dürfen auf der Website.

Deutlich wird diese Logik aber, wenn wir uns die zweite Berechtigung anschauen: Admin Anmeldung. Hier ist klar, dass nur Administratoren und Manager sich im Backend anmelden dürfen und natürlich nicht der öffentliche. Obwohl der Administrator ja erst mal öffentlich ist, bevor er sich anmeldet und erst nach der Anmeldung der Gruppe der Administratoren zugewiesen wird. Joomla muss halt erst mal wissen, zu welcher Gruppe der User gehört.

Interessant ist der Offline Zugang, den es erst seit der Version 1.7 gibt. Bisher war es so, dass nur Super Benutzer sich im Frontend einer Offline geschalteten Website anmelden konnten. Durch diese Berechtigung können auch Nicht-Super-Benutzer sich auf der Offline-Seite anmelden. So mache Supportanfrage ermöglicht diese Einstellung auch einen Testuser anzulegen, mit dem sich Supporter einloggen können, aber die nicht sauber laufende Seite für die Öffentlichkeit verborgen bleibt.

Mit der Berechtigung Superadmin ist es möglich sofort alle Berechtigungen auf erlaubt zu setzen. Der Super Benutzer darf schließlich jederzeit alles. Die Berechtigung Superadmin ist denn auch der "Gottmodus".

Mit der Berechtigung Komponentenzugriff kann im Backend auf alle Bereiche dort zugegriffen werden - mit Ausnahme auf die Konfiguration. Sinn macht das natürlich nur in Kombination mit der erlaubten Admin Anmeldung.

Die nächsten Berechtigungen wirken sich unmittelbar auf die Bearbeitung von Beiträgen aus,

Die Berechtigung Erstellen ist zunächst der Dreh- und Angelpunkt! Wer nichts erstellen kann, der kann auch nichts bearbeiten. Die letzten vier Berechtigungen haben also keine Funktion, wenn Erstellen nicht erlaubt ist.
Anders ausgedrückt: Löschen, Bearbeiten, Rechte bearbeiten und Eigene Inhalte bearbeiten funktionieren nur in Kombination mit der Berechtigung Erstellen.

Zwar ist denkbar, dass auch jemand andere Beiträge bearbeiten kann, wenn er selber keine Beiträge erstellen kann, aber "Bearbeiten" ist ja quasi wie "Erstellen". Ergo muss diese Berechtigung auch explizit "erlaubt" sein.

Die Berechtigung Löschen bedeutet, dass im Backend ein Beitrag endgültig gelöscht werden kann. Dazu sind aber Backend-Zugriffe notwendig.

Die Erlaubis zum Bearbeiten gibt dann im Frontend die kleinen Icons bei den Beiträgen aus. Wobei ein blaues Icon bedeutet, dass der Beitrag noch nicht veröffentlicht wurde und ein orangenes , das der Beitrag bereits veröffentlicht wurde.

Mit der Berechtigung Rechte bearbeiten ist gemeint, dass der Status verändert werden kann.

Der Status ist zuständig, um Beiträge zu veröffentlichen, sperren, zu archivieren oder zu löschen.

Eigene Inhalte bearbeiten ermöglicht es, den eigenen Beitrag zu bearbeiten, nicht jedoch zu veröffentlichen oder andere Beiträge zu bearbeiten.

Man kann bei den Standardeinstellungen sehr gut sehen, was wann wie und wo bewirkt wird.

Beispiel: Redaktionssystem

Ein mögliches Szenarium wäre beispielsweise ein Redaktionssystem. Verschiedene Redaktionsgruppen, die nur in zugewiesenen Kategorien schreiben dürfen. Die einzelnen Redaktionen dürfen nur in ihren eigenen Kategorien Beiträge veröffentlichen - nicht jedoch in den Kategorien der anderen Redaktionsgruppen. Ein Chefredakteur kann Beiträge bearbeiten, löschen und über das Backend auch wieder herstellen. Allerdings darf er im Backen nur die Beiträge bearbeiten und sonst nichts.

Als erstes gehen wir wieder in unsere Gruppenansicht und legen neue Benutzergruppen an:

Diesmal benötigen wir drei Gruppen. Unser Chefredakteur ist zwar nur eine Einzelperson, die wird aber einer Benutzergruppe zugeordnet, da wir sonst das Rechtesystem nicht einstellen können.

Die beiden Redaktionen werden unter dem "Registriert" zugeordnet, der Chefredakteur unter dem "Manager".  Der Chefredakteur wird deshalb in die Hierarchieebene des Managers zugeordnet, weil der Chefredakteur einen Backend-Zugang erhalten wird und ich den so über das "vererben" bereits zugeordnet habe.

Individuelle Zugriffsebenen benötigen wir für dieses Beispiel nicht, da ansonsten die User der Redaktionen ja überall hin Zugriff haben sollen.

Jetzt legen wir die Kategorien an. Die beiden Politik-Kategorien Wirtschaft und Ausland legen wir in eine übergeordnete Kategorie Namens "Politik". Das deswegen, weil wir dann per Menü auf beide Politik-Kategorien gleichzeitig zugreifen können.

In der Konfiguration stellen wir bei den beiden Benutzergruppen, neben der erlaubten Seiten Anmeldung, noch die beiden Berechtigungen Erstellen und Eigene Inhalte bearbeiten auf Erlaubt.

Leider gibt es an dieser Stelle eine unschöne Lösung bei Joomla. Wenn der Beitrag noch nicht veröffentlich ist, kann der Redakteur seinen Beitrag auch nicht bearbeiten. Das kann er erst, wenn der Beitrag veröffentlicht wurde. Möchte man erreichen, dass der Redakteur auch seinen unveröffentlichten Beitrag bearbeiten kann, muss man ihm die Berechtigung Rechte bearbeiten erlauben. Der Nachteil daran ist dann aber, dass der Redakteur seinen Beitrag selbstständig freigeben oder auch in den Papierkorb verschieben kann.

Chefredakteur

Der Chefredakteur soll die Beiträge bearbeiten und löschen und über das Backend Beiträge aus dem Papierkorb holen können.

Dazu geben wir ihm zunächst in der Konfiguration jede Menge vererbte Berechtigungen. Ganz besonders wichtig ist, dass der Komponentenzugriff auf vererbt oder erlaubt steht. Stellt man hier auf verweigert führt der Versuch, die Beitragskomponente im Backend freizuschalten zu einem Konflikt.

Bei einem Blick ins Backend können wir nun sehen, dass unser Chefredakteur neben seinem Profil die Beiträge bearbeiten kann und leider auch einige der standardmäßig installierten Komponenten. Glücklicherweise nur einige, so dass wir diese recht schnell so einstellen können, dass diese für den Chefredakteur auch nicht zugänglich sind.

Dazu einfach in jeder Komponente, jeweils die Optionen editieren und im Tab Berechtigungen explizit den Komponentenzugriff auf verweigert stellen.

Das müssen wir bei allen Komponenten wiederholen, die im Backend im Menü angezeigt werden. Danach ist dann aber dieses Menü verschwunden und der Chefredakteur kann nur noch auf Beiträge und Kategorien zugreifen (und auf seinem Profil auch weiterhin).

Alternativ:
Haben Sie mehrere Benutzergruppen, die Zugang zum Backend erhalten sollen, aber dort keine Komponenten sehen sollen, können Sie diesen Vorgang auch in der Benutzergruppe "Öffentlich" anwenden. Es sind dann automatisch alle weiteren Gruppen gesperrt - bis auf dem Super Benutzer.

Etwas verwirrend ist die Berechtigung Löschen:

Stellt man die auf verweigert kann der Chefredakteur dennoch Beiträge in den Papierkorb verschieben und sie dort auch wieder herausholen. Aber er kann dann keinen Beitrag endgültig löschen. Das kann er erst, wenn die Berechtigung auf erlaubt steht.