Das Handbuch steckt im Programm

Zu jedem Reiter gehört eine eigene Hilfeseite, die sich über das Fragezeichen daneben öffnet — in Odoo, ohne Wechsel in den Browser und ohne Suche auf einer Dokumentationsseite, die eine andere Ausgabe beschreiben könnte.

Sechzehn Themen decken die sechs Bereiche, einen Einstieg in dreißig Minuten und die Übertragung zwischen Systemen ab. Das Fragezeichen in der Kopfzeile öffnet die Übersicht, das am Reiter genau das Thema, an dem gerade gearbeitet wird.

Auf dem Server durchgesetzt

Ein in der Oberfläche ausgeblendetes Feld ist ein Vorschlag — wer die externe Schnittstelle kennt, geht daran vorbei. Cerberus greift in create, write und unlink des Basismodells ein und weist den Vorgang mit einer Meldung ab, die die Richtlinie beim Namen nennt.

Damit gilt dieselbe Einschränkung für die Oberfläche, für XML-RPC und für jeden Aufruf aus eigenem Python-Code.

Eine in der Datenschicht abgewiesene Schreiboperation — die Meldung nennt die Richtlinie.

Aufgeräumt oder gesperrt — pro Regel entschieden

Eine ausgeblendete Schaltfläche und eine abgewiesene Operation sehen für den Anwender gleich aus und sind sicherheitstechnisch zweierlei. Vier Einstellungen tragen deshalb einen eigenen Schalter: ein geschütztes Feld, die Sperre für Anlegen/Ändern/Löschen je Modell, die Methode hinter einer ausgeblendeten Schaltfläche und der Export. Ohne ihn räumen sie den Bildschirm auf, mit ihm weist der Server ab — gleich über welchen Weg.

Damit lässt sich „darf den Kurs bearbeiten, aber nicht veröffentlichen“ abbilden, ohne gleich alles zu sperren: Das Feld wird abgewiesen, der übrige Datensatz bleibt bearbeitbar.

Richtlinien folgen der Rolle, nicht der Namensliste

Eine Richtlinie wird Benutzern zugewiesen, Gruppen oder beidem. An eine Gruppe gebunden greift sie in dem Moment, in dem jemand die Rolle bekommt, und endet, sobald er sie verliert — auch bei denen, die die Rolle nur über eine andere, sie einschließende Gruppe halten.

Niemand muss daran denken, eine Namensliste zu pflegen, wenn eine Kollegin die Abteilung wechselt.

Wirksame Rechte auf einen Blick

Für einen beliebigen Benutzer beantwortet ein Fenster, wofür es bisher drei Bildschirme und den Entwicklermodus brauchte: welche Gruppen wirksam sind und über welche andere Gruppe jede einzelne hereinkommt, welche Zugriffsrechte und Datensatzregeln daraus folgen und welche Richtlinien greifen.

Zu jeder Richtlinie steht dabei, warum sie greift und was sie in der Datenschicht durchsetzt — der Unterschied zwischen aufgeräumtem Bildschirm und echter Sperre ist damit ablesbar statt geschätzt. Das Fenster liest nur; es ändert nichts.

Menüs, Felder und Operationen in einer Richtlinie

Eine Rolle wird im Gespräch am Stück beschrieben: „das Lager sieht Bestände, ändert Mengen, löscht nichts“. Cerberus lässt genau das als eine benannte Richtlinie aufschreiben — sechs Bereiche in einem Formular, statt derselben Rolle verteilt über Gruppen, Datensatzregeln und Ansichtsanpassungen.

Benutzer werden der Richtlinie zugeordnet, und eine Richtlinie kann für beliebig viele Benutzer gelten.

Eine Richtlinie, sechs Bereiche: Menüs, Felder, Modellzugriff, Domänen, Bedienelemente, globale Schalter.

Menüsichtbarkeit ohne Umweg

Auszublendende Menüpunkte werden direkt ausgewählt; die Richtlinie verweist unmittelbar auf die Menüeinträge, ohne Spiegel- oder Zwischentabelle.

Ein ausgeblendeter Punkt verschwindet aus der Navigation und aus dem Menüaufbau des Web-Clients — nicht nur aus der Darstellung.

Feldrechte in drei Stufen

Je Modell und Feld lässt sich festlegen: unsichtbar, schreibgeschützt oder verpflichtend. Die Regel wird beim Aufbau der Ansicht angewandt und wirkt deshalb in Formular, Liste und Suche gleichermaßen.

Bei Beziehungsfeldern lässt sich zusätzlich der Sprung auf den verknüpften Datensatz entfernen, damit ein gesperrter Bereich nicht über den Umweg eines Verweises wieder offensteht.

Datensatzoperationen je Modell

Anlegen, Ändern, Löschen, Archivieren und Duplizieren werden getrennt gesteuert — fünf Häkchen statt einer pauschalen Schreibsperre.

Im selben Schritt lässt sich festlegen, welche Ansichtsarten ein Modell überhaupt anbietet und welche Berichte und Serveraktionen aus dem Aktionsmenü verschwinden.

Datensatzgenaue Regeln über Domänen

Wo die Steuerung je Modell zu grob ist, greift eine Domäne: nur eigene Datensätze, nur die eigene Firma, nur Aufträge einer Abteilung.

Lesen, Anlegen, Ändern und Löschen tragen je eigene Häkchen — eine Auswahl kann also sichtbar sein, ohne änderbar zu sein. Die Domäne wird Odoos eigenen Datensatzregeln beigemischt und wirkt damit auf jeder Abfrage.

Schaltflächen, Reiter und Kanban-Verweise

Einzelne Schaltflächen, Notizbuchreiter und Kanban-Verweise lassen sich ausblenden — auch die Statistik-Schaltflächen am Kopf eines Formulars.

Die auswählbaren Elemente muss niemand abtippen: Cerberus liest die Ansichten des gewählten Modells aus und legt die gefundenen Elemente als Katalog an, aus dem ausgewählt wird.

Globale Schalter

Vier Schalter wirken über alle Modelle hinweg: Export, Import, „In Tabellenkalkulation einfügen“ und „Eigenschaft hinzufügen“.

Zwei weitere betreffen den Zugang selbst: der Entwicklermodus lässt sich unterbinden, und die Anmeldung eines Benutzers lässt sich sperren, ohne das Konto zu archivieren.

Schreibgeschützter Zugang mit einem Häkchen

Ein einzelnes Häkchen setzt die zugeordneten Benutzer über alle Modelle hinweg auf Lesezugriff.

Das ist der Zugang für die Betriebsprüfung, für die Einarbeitung und für externe Betrachter, der sonst aus einem Dutzend einzelner Rechte zusammengesetzt werden müsste.

Kein Aussperren möglich

Eine Richtlinie, die einen Administrator schreibgeschützt setzen oder seine Anmeldung sperren würde, wird abgewiesen — beim Anlegen, beim Ändern und beim Wiederaktivieren.

Der eine Fehler, dessen Korrektur sonst einen Datenbankzugang erfordert, lässt sich damit nicht machen.

Mehrere Firmen in einer Datenbank

Eine Richtlinie gilt entweder unabhängig von der aktiven Firma oder nur für ausgewählte Gesellschaften.

Damit trägt eine gemeinsame Datenbank unterschiedliche Rollenzuschnitte je Gesellschaft, ohne die Benutzerkonten zu verdoppeln.

Übertragung zwischen Systemen

Richtlinien lassen sich als JSON ausgeben und andernorts einlesen — wahlweise als Neuanlage oder als Aktualisierung einer bestehenden Richtlinie.

Verweise auf Menüs, Felder und Aktionen werden als XML-ID und technischer Name geschrieben, nicht als Datenbanknummer. Was auf dem Zielsystem fehlt, wird protokolliert und übersprungen, statt den Import abzubrechen.

Nachvollziehbare Änderungen

Das Richtlinienmodell hängt am Chatter: wer wann welche Einschränkung gesetzt oder zurückgenommen hat, steht am Datensatz.

Das ist die Frage, die bei einer Prüfung als Erstes gestellt wird — und sie lässt sich ohne Datenbankzugriff beantworten.