Praktischer - dynamische rollenbasierte Zugriffe

Auf dieser Seite wird erklärt, wie man beim Erstellen eines Nodes die Benutzerrollen für bestimmte Rechte auswählen kann

Manchmal reicht es nicht oder es ist nicht sinnvoll, bestimmten Rollen starr die Rechte für einen Inhaltstyp zuzuweisen.

Beispiel:
Man hat einen News-Bereich und die Rollen "Mitglieder", "Vorstand", "Ausbilder", "Verwalter". Nun kann es vorkommen, dass man News schreiben will, die nur für den Vorstand gedacht sind. Ok, macht man eben einen extra Inhaltstyp. Aber wenn es auch News gibt, die nur Ausbilder lesen sollen? Oder nur Ausbilder und Verwalter? Oder nur Verwalter und der Vorstand? Wäre es nicht praktisch, wenn man beim Erstellen des Nodes festlegen könnte "Dieser Node soll nur von den Rollen Vorstand und Verwalter gesehen werden"?

Das geht. Und nichtmal sonderlich schwer:

Die Module

Diese Aufgabenstellung ist etwas komplexer, sodass wir auf ein paar Module mehr zurückgreifen müssen:

• CCK
• Role Reference
• Node Privacy by Role
• Rules

Kurze Erklärung:
CCK dürfte jedem bekannt und von vielen benutzt sein. Role Reference arbeitet ähnlich wie Node Reference oder User Reference, man kann damit im Node bestimmte Rollen referenzieren.
Node Privacy by Role funktioniert ähnlich wie Content Access, es kann den Zugriff auf Inhaltstypen oder einzelne Nodes auf Basis der Benutzerrollen beschränken. Da die Zugriffsarbeit also von NPbR erledigt wird, benötigen wir in dieser speziellen Aufgabe nicht zwingend das Modul Content Access. Es ist allerdings problemlos möglich, beide parallel einzusetzen und für eine Art der Aufgaben Content Access zu benutzen und z.B. für diese spezielle Aufgabe hier NPbR zu verwenden.

Das Besondere an Node Privacy by Role ist, dass wir damit später die Zugriffsrechte auf Basis einen Role Reference-Feldes setzen können, was mit Content Access nicht geht.
Letztendlich benötigen wir Rules, um die Zugriffsrechte für einen neuen Node automatisch zu setzen.

Zum Zeitpunkt des Verfassens dieser Buchseiten werden folgende Versionen benutzt:

Drupal --> 6.17 (deutsche Version von DC)
CCK --> 6.x-2.7
Role Reference --> 6.x-1.2
Node Privacy by Role --> 6.x-1.5
Rules --> 6.x-1.2

Vorbereitung und Installation

Auch hier ist dieser Punkt recht einfach - Module runterladen, entpacken, nach sites/all/modules hochladen und aktivieren.

Nun kommen die einzelnen Arbeitsschritte:

1. Inhaltstyp bearbeiten und anpassen

Ich nenne meinen Inhaltstyp einmal "Test-Typ".

Zuerst müssen wir den gewünschten Inhaltstyp anpassen. Also gehen wir nach admin/content/types und klicken beim gewünschten Inhaltstyp auf "Bearbeiten". Auf der darauf folgenden Seite finden wir etwas weiter unten den Punkt "Node privacy by role".
Wenn wir darauf klicken, öffnet sich eine Box, in der wir ähnliche Rechte-Anpassungen vornehmen können wir zuvor schon bei Content Access. Man kann also bei dem gewünschten Zugriffsrecht (z.B. "Default View Permissions") eine oder mehrere Rollen auswählen. Allerdings gibt es hier nicht die Aufteilung in "alle" und "eigene", sondern die Rechte gelten immer für alle Nodes dieses Typs.

Hier könnte man also die Standardrechte für den Inhaltstyp setzen. Wir richten es nun so ein, dass keine Haken gesetzt sind, kein einziger. Damit hat niemand irgendwelche Leserechte oder ähnliches. Das hat so seine Richtigkeit, weil die Zugriffsrechte später komplett auf Basis des Role-Reference-Feldes vergeben werden.

Standardmäßig dürften auch gar keine Haken drin stehen, also einfach versichern, ob das stimmt und dann kommt Role Reference ins Spiel.

Dazu klicken wir oben auf den Reiter "Felder verwalten", um ein neues CCK-Feld anzulegen. Bezeichnung und Feldname sind frei wählbar, ich nehme einfach mal als Bezeichnung "Sichtbarkeit für Benutzerrollen" und als Feldname "field_rolereference". Dann nimmt man als Datentyp "Role Reference" und als Darstellungs nimmt man am besten "Ankreuzfelder / Auswahlknöpfe" --> ich möchte gern die entsprechenden Rollen einfach ankreuzen (allerdings funktioniert es auch mit den anderen Darstellungen).

Weiter zu den Einstellungen des Feldes:
Hilfe-Text, Standard-Wert und ob erforderlich oder nicht - euch überlassen. Bedenkt lediglich, wenn ihr "Erforderlich" nicht anwählt und keinen Standardwert angebt, kann man ,ohne eine Benutzerrolle zu wählen, einen Node speichern - den dann niemand sehen kann, weil wir bei den Default-Permissions alle Haken entfernt haben.

Auch die Anzahl der Werte ist euch überlassen. Wählt ihr hier "1" aus, bekommt ihr Radiobuttons (diese runden Felder, in die man einen Punkt setzen kann) und könnt nur eine Rolle auswählen. Alles andere resultiert in Checkboxen, mit denen ihr ihr die gewünschten Gruppen "anhaken" könnt.

Unter der Anzahl finder ihr die "Roles that can be referenced:". Dort könnt ihr anwählen, welche Rollen in dem Role Reference-Feld erscheinen sollen. Rollen, die hier nicht ausgewählt werden, können später nicht angewählt werden und bekommen die Nodes nie zu Gesicht. Wenn ihr also 10 Rollen habt und nur 4 Rollen kommen in Frage, den Inhaltstyp zu lesen - dann wählt diese 4 Rollen an.

Wie auch bei User Reference kann man sich eine View erstellen, welche nach bestimmten Kriterien bestimmte Benutzerrollen ausgibt und diese View kann man dann für die Role Reference-Ausgabe verwenden. Dann wird die gewählte Einstellung bei "Roles that can be referenced:" überschrieben und stattdessen wird die View verwendet. Für unsere Zwecke hier reicht aber die normale Einstellung.

Speichern und fertig ist Schritt 1.

2. Mit Rules die Zugriffsrechte setzen

Nun müssen wir es so einrichten, dass beim Speichern eines Nodes die Zugriffsrechte anhand des Role Reference-Feldes gesetzt werden.

Dazu rufen wir admin/rules/trigger auf und klicken auf "Neue Regel hinzufügen". Die Bezeichnung kann man frei wählen, als Ereignis nehmen wir "Nach dem Speichern von neuem Inhalt". Ob man der Regel eine Kategorie hinzufügt, kann man selbst entscheiden. Lohnt sich evtl. wenn man viele Regeln hat.
Man sollte auch beachten, dass ein Haken bei "Diese Regel ist aktiv und soll ausgewertet werden, wenn das zugehörige Ereignis stattfindet." gesetzt ist.

Nun klicken wir auf "Änderungen speichern" und gehen zur nächsten Seite.

Dort haben wir nun unter "Regel-Elemente" zwei Bereiche:

ON
--> Hier kommen Bedingungen rein. Die Regel-Aktionen werden nur ausgeführt, wenn diese Bedingungen erfüllt sind

DO
--> Hier werden die auszuführenden Aktionen eingetragen

Als erstes klicken wir auf "Bedingung hinzufügen" und wählen auf der nächsten Seite die Bedingung "Inhalt hat den Typ" aus. Danach kann man noch auswählen, für welche Inhaltstypen die Regel ausgeführt werden soll. Also wählen wir "Test-Typ" aus (wenn man STRG gedrückt hält, kann man mehrere Typen wählen) und klickt auf speichern.

Nun kann man noch weitere Bedingungen hinzufügen, aber für unsere Aufgabe hier reicht dies erstmal.

Also klicken wir auf "Aktion hinzufügen". Auf der nächsten Seite wählen wir die Aktion "Change permissions based on rolereference field" (die Aktion findet sich unter dem Gliederungspunkt "Node") und gehen zur nächsten Seite.

Dort lassen wir den Haken bei "Änderungen dauerhaft übernehmen".
Bei den "Default Permissions" lassen wir alles, wie es ist. Unter "New permission" wählt man das gewünschte Role Reference-Feld (in unserem Falle also "field_rolereference") und wählen darunter die zuzuweisenden Berechtigungen. Wir setzen einen Haken bei "Anzeigen".

Weiter unten kann man noch die Einstellungen für den Nodeautor ändern. Wenn also ein User der Rolle "Vorstand" einen Node verfasst und für die Sichtbarkeit nur die Rollen "Ausbilder" und "Verwalter" auswählt, könnte er seinen eigenen Node nach dem Speichern nicht mehr sehen (weil er eben nicht zu "Ausbilder" und "Verwalter" gehört). Wenn man das umgehen will, kann man an dieser Stelle noch die gewünschten Rechte für den Autor ergänzen.

Nun speichern wir das ganze und sind im Grunde fertig. Jetzt kann man einen Inhalt erstellen, die gewünschten Rollen auswählen und nur diese können dann den Node sehen.

Durch den Haken bei "Änderungen dauerhaft übernehmen" müssten eigentlich Änderungen an dem Role Reference-Feld übernommen werden. Das heißt, wenn man nachträglich den Node bearbeitet und die Rollen ändert (z.B. zusätzlich zu Ausbildern und Verwaltern noch "Vorstand" auswählt), wird die erstellte Rule nicht ausgeführt (da sie nur beim Erstellen neuen Inhalts aktiv wird) und trotzdem können fortan auch Leute der Rolle Vorstand den Node sehen - soweit die Theorie.

Ich musste feststellen, dass das ganze mit "Änderungen dauerhaft übernehmen" nicht immer so klappt, wie es soll. Also kann man auch auf Nummer sicher gehen:
Einfach noch eine Regel erstellen, welche exakt den gleichen Inhalt hat, wie die erste, allerdings wählen wir als Ereignis nicht "Nach dem Speichern von neuem Inhalt" sondern "Nach dem Aktualisieren bestehenden Inhalts" aus und schon ist das Problem gelöst.

Zusatz

Eine Sache muss man allerdings beachten bzw. bedenken:
Man kann pro Role Reference-Feld in einer Rule nur einen Berechtigungs-Satz speichern. Das heißt, alle Rollen eines Role-Reference-Feldes bekommen die gleichen Rechte zugewiesen.

Wenn man es also z.B. einen Inhalt erstellen und auswählen will, dass die Rolle "Vorstand" den Node lesen darf und die Rolle "Verwalter" ihn lesen und bearbeiten darf, kommt man nicht um ein zweites Role-Reference-Feld herum.

In einem Feld kann man allen gewählten Rollen Leserechte geben, in einem zweiten Feld gibt man allen gewählten Rollen Bearbeitungs-Rechte. Im höchsten Fall kommt also noch ein drittes Feld mit Lösch-Rechten dazu.

Alle drei Felder muss man dann einzeln auswerten. Allerdings kann man das alles in der selben Rule machen.
Man fügt einfach eine weitere Aktion hinzu, wählt abermals "Change permissions based on rolereference field" und wählt diesmal das zweite Role-Reference-Feld und vergibt die entsprechenden Rechte.
(und macht das ganze evtl. noch ein drittes mal, wenn man drei Role-Reference-Felder hat)

"Schlimmsten Falls" hat man also drei Felder ("field_rolereference_view", "field_rolereference_edit", "field_rolereference_delete") und drei Aktionen in der Rule (Berechtigungen für die Felder: rolereference_view -> Anzeigen; rolereference_edit -> Bearbeiten; rolereference_delete -> Löschen)

Damit kann man dann völlig frei beim Node Erstellen den einzelnen Rollen die gewünschten Rechte zuweisen.

Auf diesen Zusatz ist man aber nur angewiesen, wenn man anhand der Role Reference verschiedenen Rollen verschiedene Rechte geben will!
Wenn man einfach nur möchte, dass die gewählten Rollen den Node sehen können, reicht ein einzelnes Feld mit der obigen Beschreibung.

Damit ist man nun völlig flexibel, welche Rollen welche Nodes sehen dürfen.

Wichtig:

• Wenn man "Node Privacy by Role" aktiviert, darf man auch hier nicht vergessen, die nötigen default-Rechte zu vergeben. Zwar sollen bei dem Inhaltstyp für die Role Reference alle Defalut Permissions entfernt, aber wenn man das Modul aktiviert, stehen standardmäßig alle Default Permission für alle Inhaltstypen auf false. Man darf also nicht vergessen, für die restlichen Inhaltstypen die Zugriffsrechte zu setzen!
  
  
• Sollte man parallel zu Node Privacy by Role noch Content Access verwenden, kann man für alle anderen Inhaltstypen Content Access verwenden. Das heißt, wenn die Default Permissions von Node Privacy by Role für einen Inhaltstyp alle deaktiviert sind (und somit niemand den Node sehen könnte), jedoch Rechte bei Content Access für diesen Inhaltstypen gesetzt sind, dann gelten die Rechte von Content Access trotzdem und die dort gewählten Rollen haben die entsprechenden Rollen. Das bedeutet allerdings auch, dass man alle Rechte von Content Access für den Inhaltstyp mit Role Reference entfernen muss.