Drupal-Benutzerrollen und -Berechtigungen: Wie Universitäten steuern, wer was bearbeiten darf

Eine universitäre Web-Plattform kann mehrere Hundert Redakteure umfassen: Fakultätsverwaltungen, Fachbereichssekretariate, Kommunikationsbeauftragte, Bibliothekspersonal und studentische Hilfskräfte. Drupal fasst zusammen, was jeder von ihnen tun kann, in Rollen und vergibt Berechtigungen an diese Rollen statt an einzelne Personen. In diesem Artikel stellen wir eine Rollenstruktur vor, die der Organisation eines Campus entspricht, zeigen, wie jede Abteilung redaktionelle Kontrolle über ihre eigenen Seiten erhält, welche Berechtigungen weit mehr gewähren, als ihre Namen vermuten lassen, und wie man Zugriffsrechte entzieht, wenn Personen die Institution verlassen.

Die meisten Leitfäden zu diesem Thema erklären die technischen Abläufe hinreichend gut und bleiben dann bei einem generischen Beispiel stehen. Das lässt die schwierigere Frage unbeantwortet: Wie übersetzt man eine Organisation mit Fakultäten, Abteilungen, Forschungszentren und wechselndem studentischem Personal in ein Berechtigungsschema, das ein kleines zentrales Team tatsächlich pflegen kann? Im Folgenden arbeiten wir diese Übersetzung Schritt für Schritt durch und benennen dabei die zentralen Berechtigungen und Contributed Modules, die in jedem Schritt eine Rolle spielen.

Wie Rollen und Berechtigungen in Drupal funktionieren

Jede Aktion auf einer Drupal-Website wird durch eine Berechtigung geregelt. Jede Berechtigung deckt eine Aktion oder eine kleine Gruppe von Aktionen ab, und Berechtigungen werden von den Modulen definiert, die diese Aktionen bereitstellen. Statt Berechtigungen einzelnen Konten zuzuweisen, fasst Drupal sie in Rollen zusammen und vergibt die Rolle.

Dieser Unterschied ist auf universitärer Ebene entscheidend. Wenn eine Fachbereichssekretärin die Institution verlässt, entfernen Sie eine Rolle von einem Konto, statt eine Liste einzelner Berechtigungen zu überprüfen. Wenn die Kommunikationsabteilung entscheidet, dass Redakteure keine Seiten mehr löschen dürfen, ändern Sie eine Rolle, und die Entscheidung gilt für alle, die sie innehaben.

Die drei Rollen, mit denen jede Website beginnt

Eine neue Drupal-Website verfügt über eine Rolle für anonyme Benutzer, die für nicht angemeldete Besucher gilt, sowie eine Rolle für authentifizierte Benutzer, die jedes angemeldete Konto automatisch erhält. Je nach Installationsprofil gibt es zudem eine Administratorrolle, der jede Berechtigung auf der Website zugewiesen ist.

Daraus ergeben sich zwei Grundsätze. Berechtigungen, die der Rolle der authentifizierten Benutzer erteilt werden, gelten für jedes Konto, das Sie jemals erstellen werden – diese Rolle sollte daher auf einer Plattform mit Hunderten Redakteuren nahezu leer bleiben. Und die Administratorrolle sollte als kleine, namentlich benannte Gruppe behandelt werden, nicht als bequeme Lösung für jeden, der schnell etwas erledigen muss.

Das Konto „User 1“ und warum niemand damit arbeiten sollte

Das erste Konto, das bei der Installation angelegt wird, trägt die interne ID 1 und unterscheidet sich von allen anderen Konten. Unabhängig davon, welche Rollen es innehat oder nicht, kann User 1 jede Aktion auf der Website ausführen: sämtliche Inhalte anzeigen und bearbeiten, jedes Konto bearbeiten, Konfigurationen ändern, Module installieren und deinstallieren sowie das Update-Skript ausführen. Die Drupal-Dokumentation selbst vergleicht es mit dem Root-Konto auf einem Linux-Server. Zudem kann es über die administrative Oberfläche nicht gelöscht werden.

Die Drupal-Dokumentation nennt vier Gründe, separate administrative Konten anzulegen, statt dieses eine zu teilen – und jeder dieser Gründe wiegt an einer Universität schwerer als bei einer kleinen Website.

• Aktionen auf der Website werden protokolliert. Teilt sich das gesamte Web-Team ein Konto, kann das Protokoll nicht sagen, wer die Startseite geändert hat.
• Die Administratorrolle lässt sich sicherer konfigurieren als User 1, sodass ein versehentlicher Klick kein Modul deinstallieren kann.
• Zuständigkeiten von Personen ändern sich. Rollen können einem gewöhnlichen Konto hinzugefügt oder entzogen werden; gemeinsam genutzte Zugangsdaten können nicht von einer einzelnen Person widerrufen werden.
• Die Autorenschaft von Inhalten wird erfasst und oft angezeigt. Gemeinsam genutzte Konten machen es unmöglich nachzuvollziehen, wer eine Seite verfasst hat.

Die praktische Regel lautet: Bewahren Sie die Zugangsdaten von User 1 im Passwort-Tresor der Institution auf, verwenden Sie sie nur zur Wiederherstellung und Plattformwartung, und geben Sie jedem Administrator ein namentlich benanntes Konto mit der Administratorrolle.

Rollen summieren sich, sie ziehen nie etwas ab

Ein Benutzer kann mehrere Rollen gleichzeitig innehaben, und die Berechtigungen dieser Rollen summieren sich. Es gibt im Core keinen Mechanismus, mit dem eine Rolle eine von einer anderen Rolle erteilte Berechtigung wieder entziehen kann.

Das bringt Teams regelmäßig in Schwierigkeiten. Eine Website verfügt über eine Redakteursrolle, die Inhalte löschen kann, und jemand entscheidet, dass neue Mitarbeiter nichts löschen dürfen sollen – also wird eine eingeschränkte Redakteursrolle erstellt und zusätzlich zur bestehenden zugewiesen. Die Person hält nun beide Rollen, und die Löschberechtigung ist weiterhin vorhanden. Die einzige Möglichkeit, eine Berechtigung vorzuenthalten, besteht darin, eine Rolle zu bauen, die sie nie hatte. Sobald ein System eine subtraktive Logik zu benötigen beginnt, ist das das Signal, die Rollen neu zu gestalten, statt eine weitere hinzuzufügen.

Ein Rollenmodell, das der tatsächlichen Arbeitsweise einer Universität entspricht

Rollenstrukturen an Universitäten scheitern meist in eine von zwei Richtungen. Entweder gibt es vier Rollen, und jede Fakultät beklagt sich, dass sie ihre eigene Arbeit nicht erledigen kann, oder es gibt sechzig Rollen, die nach und nach für jede einzelne Anfrage erstellt wurden, und niemand erinnert sich mehr, was die Hälfte davon eigentlich gewährt.

Eine Struktur, die sich langfristig bewährt, trennt in der Regel zwei Fragen, die leicht vermischt werden. Welche Art von Arbeit erledigt diese Person, und in welchem Teil der Website tut sie das? Drupal-Rollen beantworten die erste Frage gut und die zweite schlecht – deshalb gibt es weiter unten den Abschnitt zum redaktionellen Zuständigkeitsbereich.

Für die erste Frage decken fünf Ebenen die meisten Institutionen ab:

• Plattformadministrator. Eine namentlich benannte Gruppe von zwei bis vier Personen in der zentralen IT, die die Administratorrolle innehaben und für Konfiguration, Module und Updates verantwortlich sind.
• Zentraler Redakteur. Mitarbeiter der Kommunikations- und Marketingabteilung, die auf der gesamten Website veröffentlichen, einschließlich Startseite und institutionsweiter Seiten.
• Bereichsredakteur. Mitarbeiter von Fakultäten und Abteilungen, die innerhalb ihres eigenen Bereichs erstellen und veröffentlichen. Dies ist mit Abstand die größte Gruppe.
• Mitwirkender. Akademiker, studentische Hilfskräfte und gelegentliche Mitwirkende, die Inhalte entwerfen, die jemand anderes veröffentlicht.
• Betrachter. Konten, die für den Zugriff auf eingeschränkte Seiten existieren, nicht zum Bearbeiten – etwa für interne, nur für Mitarbeiter zugängliche Richtliniendokumente.

Zwei Tests lohnen sich, bevor eine sechste Ebene hinzugefügt wird. Würde sich eine neue Rolle von einer bestehenden um mehr als zwei Berechtigungen unterscheiden? Und wird sie jemals jemand außer dem Antragsteller innehaben? Eine Rolle, die für eine einzelne Person erstellt wurde, ist letztlich eine Berechtigungsvergabe mit Umweg – und sie wird noch Jahre bestehen, nachdem diese Person die Institution verlassen hat.

Abteilungen ihren eigenen redaktionellen Zuständigkeitsbereich geben

Rollen beantworten, was jemand tun kann, aber nicht, wo er es tun kann. Eine Bereichsredakteur-Rolle, die die Berechtigung „jede Seite bearbeiten“ gewährt, erlaubt es der Biologie-Abteilung, die Zulassungsseiten zu bearbeiten. Um das zu lösen, ist eine zweite Ebene erforderlich, und Drupal bietet zwei etablierte Ansätze.

Bereichsbasierter Zugriff mit Workbench Access

Das Workbench-Access-Modul erstellt eine redaktionelle Zugriffskontrolle auf Basis einer bereits vorhandenen Hierarchie, typischerweise einer Taxonomie von Fakultäten und Abteilungen oder der Menüstruktur der Website. Inhalte werden bei ihrer Erstellung einem redaktionellen Bereich zugeordnet, Benutzer werden Bereichen nach Konto oder nach Rolle zugewiesen, und sie können nur innerhalb ihrer eigenen Bereiche oder der darunterliegenden Bereiche agieren. Version 2.0.5 wurde im September 2026 veröffentlicht und unterstützt Drupal 9, 10 und 11. Rund achttausend Websites geben an, es zu verwenden; die Entwicklung wurde von Palantir.net gesponsert, mit Unterstützung der Charles Darwin University.

Zwei Einschränkungen aus der eigenen Dokumentation lohnen sich, sorgfältig zu lesen, bevor man darauf aufbaut. Das Modul gewährt keine redaktionellen Rechte; es beschränkt lediglich, an welchen Inhalten ein Benutzer arbeiten darf, sodass die zugrunde liegenden Erstellungs- und Bearbeitungsberechtigungen weiterhin über Rollen vergeben werden müssen. Zudem regelt es ausschließlich den Bearbeitungszugriff, nicht, wer veröffentlichte Inhalte einsehen kann.

Die Hierarchie ist es, die dies für den Hochschulbereich passend macht. Ein Kommunikationsbeauftragter einer Fakultät, der dem Fakultätsbereich zugewiesen ist, erbt jede darunterliegende Abteilung, während eine Fachbereichssekretärin, die einer einzelnen Abteilung zugewiesen ist, nur diese sieht. Wird ein neues Forschungszentrum gegründet, wird es der Hierarchie hinzugefügt, statt eine neue Rolle zu erfordern.

Wann Group besser passt als Bereiche

Das Group-Modul verfolgt einen anderen Ansatz. Statt Inhalte in eine Hierarchie einzuordnen, erstellt es Sammlungen mit eigener Mitgliedschaft und eigenen Rollen. Jemand kann Administrator einer Gruppe und einfaches Mitglied einer anderen sein, und Gruppenrollen sind von websiteweiten Rollen getrennt. Es wird auf rund achtzehntausend Websites eingesetzt.

Group eignet sich für Fälle, in denen die Grenze durch Mitgliedschaft und nicht durch organisatorische Position definiert wird: ein Forschungsprojekt mit namentlich benannten Mitarbeitern aus drei Fakultäten, ein Konferenzkomitee, eine Alumni-Gemeinschaft mit privaten Inhalten. Folgt die Grenze dagegen dem Organigramm, sind Bereiche einfacher zu betreiben.

Die Wahl der Version erfordert Ende 2026 besondere Sorgfalt. Die Zweige 2.x und 3.x unterstützen Drupal 10 und 11, der Zweig 8.x-1.x erreichte Mitte 2026 zusammen mit Drupal 10 das Ende des Supports, und ein 4.x-Zweig für Drupal 11.4 und höher befindet sich im Alpha-Stadium. Eine Plattform, die jetzt startet, sollte nicht auf dem ältesten Zweig beginnen.

Rollen auf einer Multisite-Plattform

Auf einer Plattform, auf der jede Fakultät ihre eigene Website aus einer gemeinsamen Codebasis betreibt, werden Rollen und Benutzer standardmäßig nicht zwischen diesen Websites geteilt. Jede Website hat ihre eigenen Konten und ihre eigene Rollenkonfiguration – ein Vorteil für die Autonomie, aber eine Belastung für die Konsistenz: Eine auf einer Website verbesserte Rollendefinition verbessert sich nirgendwo sonst. Der Export der Rollenkonfiguration und ihre Verteilung über mehrere Websites hält die Definitionen identisch, auch wenn die Konten getrennt bleiben. Die umfassenderen Abwägungen dieser Architektur haben wir in Verwaltung universitärer Websites mit Drupal Multisite behandelt.

Dies ist auch der Punkt, an dem die Wahl zwischen Multisite und Bereichen sichtbar wird. Benötigen Abteilungen getrennte Websites, existieren Rollen pro Website. Benötigen sie lediglich einen getrennten Zuständigkeitsbereich innerhalb einer Website, erledigen Bereiche diese Aufgabe.

Berechtigungen, die still und leise alles gewähren

Manche Berechtigungen lesen sich wie eng begrenzte administrative Erleichterungen, entsprechen in der Praxis aber der Übergabe der gesamten Website. Drupal kennzeichnet die gefährlichsten davon selbst: Eine Berechtigung kann in ihrer Moduldefinition mit einem Kennzeichen für eingeschränkten Zugriff versehen werden, wodurch die Berechtigungsseite eine standardmäßige Sicherheitswarnung daneben anzeigt. Der Core nutzt dies etwa für Berechtigungen wie die Verwaltung von Textformaten und Filtern.

Auf einer Seite mit mehreren hundert Kontrollkästchen lässt sich die Warnung leicht überlesen, daher verdienen diese Berechtigungen eine namentliche Nennung.

• Berechtigungen verwalten. Wer diese besitzt, kann sich selbst oder jeder anderen Person jede beliebige Berechtigung auf der Website erteilen, einschließlich dieser selbst.
• Benutzer verwalten. Erlaubt das Bearbeiten jedes Kontos. In Kombination mit der obigen Berechtigung – oder auf einer Website, auf der ein Administratorkonto bearbeitet werden kann – ist dies ein Weg zur vollständigen Kontrolle.
• Textformate und Filter verwalten. Steuert, welches HTML erlaubt ist und welche Rollen welches Format verwenden dürfen. Das Lockern eines Formats ist der Weg, auf dem Script-Injection über den Editor in eine Website gelangt.
• Zugriffskontrolle für Inhalte umgehen. Überschreibt jede andere Inhaltsberechtigung, einschließlich allem, was Workbench Access oder Group durchsetzt.
• Site-Konfiguration verwalten. Betrifft Einstellungen, die die gesamte Plattform beeinflussen, nicht nur einen einzelnen Website-Bereich.
• Module verwalten. Das Installieren von Code ist der direkteste Weg, beliebigen Code auf dem Server auszuführen.

Die daraus folgende Regel ist kurz. Diese Berechtigungen gehören zur Rolle des Plattformadministrators – und nirgendwo sonst hin. Trifft eine Anfrage für eine davon ein, besteht die sinnvolle Antwort darin, zu fragen, was die Person eigentlich erreichen möchte, denn die Antwort ist fast immer eine engere Berechtigung oder eine Bereichszuweisung.

Es lohnt sich, eine Behauptung zu korrigieren, die in älteren Texten zu diesem Thema kursiert: dass Contributed Modules von Natur aus weniger sicher seien als der Core. Contributed Modules mit stabilen Releases unterliegen der Sicherheitsberatungsrichtlinie von Drupal, und alle in diesem Artikel genannten Module fallen unter diesen Schutz. Was tatsächlich variiert, ist der Pflegestatus, der auf jeder Projektseite angegeben ist und den man überprüfen sollte.

Abteilungen die Verwaltung ihrer eigenen Mitarbeiter überlassen

Bei einigen hundert Redakteuren wird jede Kontoänderung, die über die zentrale IT läuft, zu einer Warteschlange. Eine Abteilung stellt im September eine Administratorin ein und wartet eine Woche auf den Bearbeitungszugriff. Die naheliegende Lösung besteht darin, dem Abteilungsleiter die Möglichkeit zu geben, Benutzer zu verwalten – was bedeutet, die Berechtigungen „Benutzer verwalten“ und „Berechtigungen verwalten“ zu erteilen, was wiederum bedeutet, dass der Abteilungsleiter sich nun selbst alles erteilen kann.

Genau dafür existiert das Role-Delegation-Modul. Es erstellt für jede Rolle auf der Website eine separate Zuweisungsberechtigung, sodass ein Fakultätsadministrator die Möglichkeit erhalten kann, die Rolle „Mitwirkender“ zuzuweisen – und nichts weiter. Sie sehen ein Rollenzuweisungs-Widget in Kontoformularen und bei Massenoperationen in der Benutzerliste, ohne die Berechtigung „Berechtigungen verwalten“ überhaupt innezuhaben. Es wird von mehr als fünfzigtausend Websites gemeldet, und die aktuelle Version unterstützt Drupal 10.3 und 11.

Delegation funktioniert am besten mit einer klaren Regel dazu, welche Rollen delegiert werden dürfen: Bereichsredakteur und Mitwirkender ja, zentraler Redakteur und Plattformadministrator nein. So bleibt die alltägliche Einarbeitung lokal, während die Rollen mit echter Macht beim zentralen Team verbleiben.

Rollenzuweisung über das Identitätssystem des Campus

Manuelle Zuweisung skaliert auf einem Campus nicht – und muss es auch nicht. Wenn sich Mitarbeiter über den Identity Provider der Institution anmelden, können die bei dieser Anmeldung freigegebenen Attribute die Rollenzuweisung direkt steuern, sodass die Mitgliedschaft in einer Verzeichnisgruppe zu einer Drupal-Rolle wird, ohne dass jemand das Konto anfasst. Die Authentifizierungsseite haben wir in SSO-Integration mit SAML, Shibboleth, LDAP und CAS behandelt; im Folgenden geht es darum, was nach Ankunft der Identität geschieht.

Zwei Modulfamilien stellen dies bereit. Das Modul simpleSAMLphp Authentication bietet eine Just-in-Time-Kontoerstellung sowie automatische Rollenzuweisung aus SAML-Attributen und ist weiterhin weit verbreitet. Seine Projektseite trägt inzwischen den Status „minimal gepflegt“, und der eigene Maintainer empfiehlt, stattdessen das SAML-Authentication-Modul zu evaluieren, das eine deutlich kleinere Abhängigkeitskette aufweist. Dieses zweite Modul handhabt die Rollenzuweisung über sein Submodul für Benutzerrollen, und ein begleitendes Modul bildet SAML-Attribute auf Group-Mitgliedschaften ab – für Institutionen, die Gruppen statt Bereiche verwenden.

Unabhängig vom gewählten Weg sind drei Designentscheidungen wichtiger als die Modulwahl selbst. Legen Sie fest, welches Attribut maßgeblich ist – üblicherweise eine Verzeichnisgruppe statt eines Jobtitel-Felds. Legen Sie fest, was bei jeder Anmeldung geschieht: ob Rollen jedes Mal neu berechnet werden, was den Entzug automatisch macht, oder nur einmal bei der Kontoerstellung zugewiesen werden, was dies nicht leistet. Und halten Sie eine kleine Gruppe von Rollen außerhalb der automatisierten Zuordnung, denn die Rolle des Plattformadministrators sollte eine bewusste Handlung sein und nicht die Folge einer Verzeichnisänderung.

Der Teil, den die meisten Institutionen überspringen: Zugriff entziehen

Berechtigungsschemata werden beim Launch entworfen und danach nur noch erweitert. Der Zugriff häuft sich an: die studentische Hilfskraft, die ihren Abschluss gemacht hat, der Mitarbeiter, der an eine andere Fakultät gewechselt ist, die Agentur, die die Website vor drei Jahren gebaut hat. Jedes dieser Konten ist immer noch ein Zugangsweg.

Eine Universität hat eine besondere Ausprägung dieses Problems, weil die Fluktuation saisonal und vorhersehbar ist. Studentisches Personal wechselt jedes Semester. Akademische Verwaltungsaufgaben rotieren jährlich. Abteilungen fusionieren. Nichts davon erzeugt automatisch eine Benachrichtigung an das Web-Team.

Drei Gewohnheiten decken den größten Teil des Risikos ab.

• Koppeln Sie die Deaktivierung an das Identitätssystem. Werden Konten aus dem Verzeichnis bereitgestellt und Rollen bei jeder Anmeldung neu berechnet, verliert eine Person, die ihre Verzeichnisgruppe verliert, ihre Bearbeitungsrechte, ohne dass jemand einen Antrag stellen muss.
• Überprüfen Sie Rollen nach dem akademischen Kalender statt nach einem willkürlichen Datum. Eine Prüfung zu Beginn jedes Semesters erfasst den Wechsel studentischer Mitarbeiter, während die Änderung noch aktuell ist.
• Sperren Sie Konten, statt sie zu löschen. Das Sperren entzieht den Zugriff, während die Autorenschaft erhalten bleibt, sodass die Historie, wer was geschrieben hat, erhalten bleibt.

Eine kurze, einmal pro Semester von einer namentlich benannten Person überprüfte Liste darüber, wer die Rollen Plattformadministrator und zentraler Redakteur innehat, ist mehr wert als jede noch so umfangreiche Richtliniendokumentation.

Personenbezogene Daten und die Berechtigungsebene

Sobald eine Website Bewerbungsformulare, Veranstaltungsanmeldungen oder aus einem anderen System stammende Studierendendaten enthält, wird das Berechtigungsschema zu einer Datenschutzkontrolle statt zu einer bloßen redaktionellen Erleichterung.

In den Vereinigten Staaten unterscheidet FERPA zwischen Bildungsdaten (education records) und Verzeichnisinformationen, und welche Felder in welche Kategorie fallen, ist eine Entscheidung des Studierendensekretariats (registrar), nicht des Web-Teams. In der Europäischen Union und im Vereinigten Königreich weist der Grundsatz der Datenminimierung in der DSGVO in dieselbe Richtung: Personen sollten nur auf die Daten zugreifen können, die ihre Arbeit erfordert, und nicht mehr.

Daraus ergeben sich drei praktische Punkte. Eine feldbasierte Berechtigungskontrolle erlaubt es einem Formular, ein Feld zu erfassen, das die meisten Redakteure nicht wieder auslesen können – die richtige Lösung für Kontaktdaten in einem Anfrageformular. Der Zugriff auf eingereichte Formulardaten sollte eine eigene Rolle sein, getrennt von der Fähigkeit, die Seite mit dem Formular zu bearbeiten, denn die Person, die eine Studiengangseite pflegt, benötigt selten die eingegangenen Bewerbungen. Und die Berechtigung, unveröffentlichte Inhalte einzusehen, ist weitreichender, als sie erscheint, da Entwürfe oft genau das Material enthalten, das noch nicht zur Veröffentlichung freigegeben wurde.

Ein Berechtigungsschema überprüfen und testen

Ein Berechtigungsschema ist Konfiguration – das bedeutet, es kann exportiert, wie Code überprüft und deployt werden, statt direkt auf der Live-Website zusammengeklickt zu werden. Institutionen, die es so handhaben, können auch Monate später beantworten, was sich geändert hat und wann.

Das Testen ist der Schritt, der übersprungen wird. Die einzig verlässliche Prüfung besteht darin, für jede Rolle ein Testkonto vorzuhalten, sich damit anzumelden und zu versuchen, Dinge zu tun, die die Rolle eigentlich nicht können sollte. Das Lesen der Berechtigungsseite zeigt Ihnen, was Sie konfiguriert haben; die Nutzung des Kontos zeigt Ihnen, was Sie tatsächlich gebaut haben. Es lohnt sich, pro Rolle ein ruhendes Testkonto auf der Plattform genau zu diesem Zweck vorzuhalten.

Eine Abgrenzung sollte klar benannt werden, da sie häufig Verwirrung stiftet. Berechtigungen entscheiden, was eine Person tun darf. Der redaktionelle Workflow entscheidet, in welchem Zustand sich ein Inhalt befindet und wer ihn in den nächsten Zustand überführt. Dass ein Mitwirkender eine Seite erstellen, aber nicht veröffentlichen kann, ist eine Berechtigungsentscheidung; dass eine Seite so lange in der Überprüfung verbleibt, bis ein Redakteur sie freigibt, ist eine Workflow-Entscheidung. Beide arbeiten zusammen, und den zweiten Aspekt haben wir in Freigabe-Workflows für Inhalte an Universitäten behandelt.

Ihre Rollenstruktur planen

Die Arbeit, die darüber entscheidet, ob ein Berechtigungsschema Bestand hat, ist nicht die Konfiguration. Es geht darum, festzulegen, welche Einheiten welche Teile der Website besitzen, wer ohne Überprüfung veröffentlichen darf, welche Rollen eine Fakultät selbst zuweisen kann und was geschieht, wenn jemand die Institution verlässt. Diese Antworten kommen von der Institution, und Drupal setzt sie anschließend um.

Eine sinnvolle Reihenfolge besteht darin, zunächst die bestehende Inhaltszugehörigkeit abzubilden, dann die kleinstmögliche Menge an Rollen zu definieren, die die Arbeit abdeckt, eine Bereichshierarchie hinzuzufügen, damit diese Rollen nur innerhalb einer Einheit gelten, die beiden untersten Rollen an die Fakultäten zu delegieren, die Zuweisung an das Identitätssystem anzubinden und ein Überprüfungsdatum im akademischen Kalender festzulegen – bevor die Plattform live geht, nicht danach.

Die Drupal-Plattformen, die das Drupal4edu-Team bei Drupart für Institutionen wie die Sabancı-Universität, die METU und die Yıldız Technische Universität aufgebaut hat, sind genau um diese Ebene herum konzipiert: Ein kleines zentrales Team hält die Plattform konsistent, während jede Fakultät ihre eigenen Seiten bearbeitet. Mehr über unseren Ansatz erfahren Sie auf der Seite Drupal für die Bildung.

Häufig gestellte Fragen zu Drupal-Rollen und -Berechtigungen

Letzte Aktualisierung: 18.09.2026 15:52