Wie Rechte berechnet werden

Diese Seite ist noch nicht vollständig übersetzt.

Siehe en:How_permissions_are_calculated

Eine der am häufigsten gestellten Fragen lautet: "Was sind meine Rechte in diesem Kontext?" In diesem Artikel wird die Funktion beschrieben, die Moodle verwendet, um diese Frage zu beantworten. Der Artikel ist sowohl für Nicht-Programmierer als auch Programmierer geschrieben, denn er beschreibt, was diese Funktion tut, nicht wie sie es tut. Das Wie ist kompliziert, das Was dagegen ist relativ einfach zu verstehen. Wenn Sie Programmierer sind und den entsprechenden Code lesen möchten, suchen Sie die Funktion has_capability() im PHP-Skript lib/accesslib.php.

Zu einem gegebenen Nutzer, einer gegebenen Fähigkeit und einem gegebenen Kontext liefert die Funktion has_capability() ein true (wahr), wenn der Nutzer im gegebenen Kontext das Recht hat, die Aktion, die durch die gegebene Fähigkeit gesteuert wird, durchzuführen, und andernfalls liefert sie false (falsch). Bei der Berechnung des Ergebnisses berücksichtigt die Funktion alle relevanten Rechte-Daten, inklusive Rollendefinitionen, Rollenzuweisungen und Rollenänderungen.

Moodle berechnet nie den "Gesamtsatz" aller Rechte eines Nutzers. Das wäre sehr teuer, zeitaufwändig und unnütz, weil die meisten Rechte in einer gegebenen Situation nicht relevant sind. Stattdessen berechnet Moodle Rechte nur dann, wenn es nötig ist. Diese Rechte werden auch nicht gespeichert, sondern bei Bedarf jedes Mal neu berechnet. Daher gibt es auch keine "Verzögerungseffekte" mehr (etwa wenn Sie Rollen ändern), wie das in Moodle 1.7, 1.8 der Fall ist.

Übrigens können Sie mit Hilfe des PHP-Skripts rolesdebug.php Rechte-Tabellen, wie sie in diesem Artikel weiter unten vorkommen, generieren.

Der Berechnungsalgorithmus

Wenn ein Nutzer versucht, eine Aktion auszuführen, die durch eine Fähigkeit kontrolliert wird, ruft Moodle die Funktion has_capability() auf, um zu prüfen, ob der Nutzer das Recht dazu hat. Der Funktionsaufruf lautet:

 has_capability(CAP,CONTEXT,USER);

wobei

• CAP die Fähigkeit ist, die die Aktion steuert (z.B. mod/quiz:attempt),
• CONTEXT der Kontext ist, in dem die Fähigkeit geprüft wird, und
• USER der Nutzer ist, der versucht, die Aktion auszuführen.

Die Funktion liefert als Ergebnis ein true (wahr) oder false (falsch):

• true bedeutet, dass der Nutzer die Aktion ausführen darf,
• false bedeutet, dass der Nutzer die Aktion nicht ausführen darf.

Daten, die die Funktion verwendet

Nehmen wir an, ein Nutzer USER versucht, einen Test durchzuführen, d.h. CAP = mod/quiz:attempt, und zwar in einem Modul-Kontext, der über vier Ebenen im System-Kontext verschachtelt ist:

     System
        |
    Kursbereich A
        |					      
   Unterkursbereich B
        |
      Kurs
        |
      Test <--- der Nutzer ist hier

Das Test-Modul ruft die Funktion has_capability(), um zu prüfen, ob der Nutzer den Testversuch durchführen darf.

Die Funktion has_capability() prüft nun folgende Rechte-Daten:

• Rollendefinitionen (diese sind im System-Kontext),
• Rollenzuweisungen, die in jedem der fünf Kontexte vorhanden sein können,
• Rollenänderungen, die in jedem der fünf Kontexte vorhanden sein können, außer im System-Kontext (im System-Kontext gibt es das Konzept der Rollenänderung nicht).

Die Funktion has_capability() ignoriert alle anderen Fähigkeiten und prüft nur die Fähigkeit CAP. Aufgrund dieser Vereinfachung können wir jede Rollenzuweisung oder -änderung als mit einem "einfachen Recht" belegt betrachten, wobei dieses Recht einen der folgenden Werte annehmen kann:

   N - Not set (nicht gesetzt)
   A - Allow (erlaubt)
   P - Prevent (unterbunden)
   X - Prohibit (untersagt)

Im weiteren nutzen wir die folgende Notation: Für eine Rolle R1 mit einem Recht P schreiben wir R1(P).

Beispiel

Nehmen wir im obigen Beispiel mit dem Testversuch durchführen an, der Nutzer hat vier Rollen, die wie folgt in den verschiedenen Kontexten zugewiesen oder geändert sind:

   0     System           <---- Rollendefinitionen: R1(A), R2(N), R3(N), R4(P)
           |                    Rollenzuweisungen: R1
           |
   1   Kursbereich A      <---- Rollenänderungen:  R1(N) und R4(N)
           |                          
           |                          
   2  Unterkursbereich B  <---- Rollenzuweisungen: R2 und R3
           |
           |
   3     Kurs             <---- Rollenänderungen: R2(X) und R3(A)
           |
           |
   4     Test             <---- Rollenzuweisungen: R4 und R1

Beachten Sie, dass die Rolle R1 in zwei verschiedenen Kontexten (System und Test) zugewiesen wurde. Das entspricht eigentlich nicht der gängigen Praxis (und wurde vermutlich von jemandem falsch gemacht). Da es aber in Moodle trotzdem, erlaubt ist, müssen wir es als Möglichkeit mit in Betracht ziehen. Tatsächlich wurde dieses Beispiel extra gewählt, um den Algorithmus auch für Grenzfälle zu testen. In der Praxis ist die Berechnung von Rechten trivial, und der Algorithmus berechnet das Ergebnis so, wie es der gesunde Menschenverstand erwartet und einfache logische Analyse ergibt (siehe auch den Abschnitt Anmerkung zum Algorithmus weiter unten).

Siehe auch

Diskussionsbeiträge im Kurs Using Moodle auf moodle.org:

• Logged in: what role am I?
• What happens if a user has multiple roles in a course?

Skript zum Testen von Rollen:

• rolesdebug.php