In diesem Beitrag
Odoo-20-Rechtemigration: Gesellschaftstrennung prüfen
Im fiktiven Beispiel unten wechselt derselbe Zugriff für denselben Nutzer nach einer naiven Rechteumstellung von verweigert zu erlaubt. Die gewünschte Geschäftsregel bleibt gleich. Verändert hat sich, wie die Berechtigungen zusammenwirken.
Nimm eine Odoo-20-Rechtemigration erst ab, wenn die freigegebene Rollen- und Gesellschaftsmatrix erlaubte und verbotene Operationen auf der aktualisierten Datenbank besteht. Prüfe konvertierte Grants und globale Einschränkungen. Teste aktivierte Gesellschaften getrennt von Werten der aktuellen Gesellschaft. Eine erfolgreiche Installation oder ein Administrator-Rundgang liefert diese Nachweise nicht.
Recherchestand: 5. November 2026. Wir haben offizielle Odoo-19- und Odoo-20-Dokumentation, die Zugriffsimplementierung für 20.0 und ihr Konvertierungsskript untersucht. Sechzehn fiktive Python-Regelfälle wurden ausgeführt. Odoo, Datenbankupgrade und offizieller Konverter wurden nicht ausgeführt. Die native Abnahmematrix bleibt NOT_RUN.
Was ändert Odoo 20 an der Zugriffskontrolle?
Odoo 20 führt Operationen und Datensatzdomänen in einem Zugriffsmodell zusammen. Eine Rechtemigration muss deshalb die gemeinsame Wirkung der resultierenden Grants prüfen. Dass eine umbenannte Sicherheitsdatei geladen wird, reicht nicht. Erhalte eine freigegebene Referenzregel und vergleiche die tatsächlichen Ergebnisse jeder betroffenen Rolle mit diesem Soll.
Die offizielle Sicherheitsreferenz für 20.0 definiert ir.access über Gruppe, Operation und Domäne. Gruppeneinträge gewähren Zugriff; Einträge ohne Gruppe beschränken ihn. Die Referenz für 19.0 beschreibt getrennte Modell-ACLs mit nachfolgenden Datensatzregeln.
Erfasse eigene Sicherheitsdatensätze und die Geschäftslogik, die davon abhängt. Ordne jedem Eintrag seine Regel zu, etwa „Fallverantwortliche lesen eigene Fälle ihrer Gesellschaft“ oder „Prüfer lesen alle Fälle der aktivierten Gesellschaften“. Das sind unterschiedliche Regeln, auch wenn beide Nutzer dasselbe Menü öffnen können.
Der Leitfaden zur Odoo-Migrationsabnahme behandelt Daten und Prozessfortsetzung. Hier geht es enger um Zugriffsrechte. Auch ein fachlich korrekt migrierter Auftrag ist nicht akzeptabel, wenn ihn die falsche Identität abrufen kann.
Wie wirken Gruppengrants und globale Einschränkungen zusammen?
Bei einer gewöhnlichen Zugriffsprüfung braucht ein Datensatz mindestens einen passenden Gruppengrant und muss jede zutreffende globale Einschränkung erfüllen. Im Beispiel erweitert ein breiter Grant die lesbaren Datensätze, während die globale Gesellschaftsregel diese Erweiterung begrenzt. Eine Einschränkung allein erteilt keinen Zugriff. Prüfe deshalb Kombinationen statt einzelner Zeilen.
Das Modell drückt die Entscheidung so aus:
mindestens ein passender Gruppengrant
UND
jede zutreffende globale EinschränkungUnsere erfundene Gruppe own_reader gewährt Zugriff nur auf Datensätze von Nutzer 7. Eine gesonderte globale Regel begrenzt sie auf aktivierte Gesellschaften. Nutzer 7 darf A-OWN lesen, aber nicht A-OTHER. Mit broad_reader wird auch der zweite Datensatz lesbar, weil eine weitere passende Gewährung hinzukommt.
Gesellschaft B bleibt nun inaktiv. Trotz breiter Gruppe bleibt B-OWN gesperrt, solange die globale Gesellschaftsregel gilt. Entfernst du sie in der absichtlich fehlerhaften Modellkonfiguration, wird derselbe Datensatz lesbar. Der Test zeigt die fehlende Grenze. Er behauptet nicht, dass Odoo diese Grenze standardmäßig auslässt.
Prüfe auch einen berechtigten Zugriff. Zwei widersprüchliche globale Einschränkungen, eine nur für A und eine nur für B, sperren ihn im Beispiel. Ein Testpaket mit ausschließlich verbotenen Zugriffen könnte diese kaputte Konfiguration als Erfolg werten. Jede wichtige Verweigerung braucht einen erlaubten Kontrollfall.
Welchen Gesellschaftskontext muss der Test erfassen?
Erfasse Mitgliedschaften, aktivierte Gesellschaften und aktuelle Gesellschaft getrennt. Sie beschreiben, welche Gesellschaften der Nutzer wählen darf, welcher Umfang für diese Operation aktiv ist und welche Gesellschaft kontextabhängige Werte liefert. Ein Abnahmeergebnis ohne diesen Kontext kann nicht erklären, weshalb ein bestimmter Datensatz sichtbar oder verborgen war.
Die Domänenauswertung für Zugriff in 20.0 setzt company_ids aus env.companies.ids, also den aktivierten Gesellschaften, und company_id aus env.company.id. Ersetze den getesteten Umfang nicht durch sämtliche Mitgliedschaften des Nutzers.
| Dimension | Beispiel | Abnahmefrage |
|---|---|---|
| Berechtigte Mitgliedschaft | Nutzer 7 gehört zu A und B. | Darf diese Identität B überhaupt auswählen? |
| Aktivierte Gesellschaften | Für diesen Aufruf ist nur A aktiv. | Schließt eine gesellschaftsbezogene Operation Datensätze aus B aus? |
| Aktuelle Gesellschaft | A ist aktuell, während A und B aktiv sind. | Den Wert welcher Gesellschaft verwendet die Operation? |
| Datensatzzugehörigkeit | B-OWN gehört zu B. | Gehört der resultierende Datensatz zur vorgesehenen Gesellschaft? |
Die Environment-Implementierung prüft die gewählten Gesellschaften gewöhnlicher Nutzer, verwendet bei leerer Liste einen Rückfall und überspringt die genannten Plausibilitätsprüfungen im sudo-Modus. Eine leere Liste bedeutet daher nicht „alles verweigern“. Ausführung mit erhöhten Rechten belegt keine Isolation normaler Nutzer.
Das Modell macht den Unterschied sichtbar. Bei Mitgliedschaften A/B und nur aktivem A wird der eigene B-Datensatz verweigert. Mit aktivem A/B wird er erlaubt. Ein Nutzer mit ausschließlich A darf im Modell B nicht aktivieren. Halte diese Fälle getrennt fest, statt sie unter „Multi-Company funktioniert“ zusammenzufassen.
Warum kann eine naive ACL-Konvertierung Zugriff ausweiten?
Eine naive Umstellung kann einen alten breiten Modellgrant als breiten Datensatzgrant neben einem engeren Grant erhalten. Im Gegenbeispiel besitzt der Nutzer beide Gruppen. Die alte gestufte Regel verweigert einen fremden Datensatz; die neue Vereinigung erlaubt ihn. Das zeigt eine fehlerhafte Umschreibung, kein Ergebnis des offiziellen Odoo-Konverters.
| Stufe | Modellregel | A-Datensatz eines anderen Besitzers |
|---|---|---|
| Altes gestuftes Beispiel | Eine Modell-ACL erlaubt Lesen; eine geltende Eigenbesitzregel filtert das Ergebnis. | Verweigert |
| Naive neue Fassung | Ein breiter Datensatzgrant wird mit einem Eigenbesitzgrant kombiniert. | Erlaubt |
| Freigegebene Zielregel | Die Rolle soll weiterhin nur eigene Datensätze lesen. | Muss verweigert bleiben |
Der offizielle Quellcode der Zugriffskonvertierung berücksichtigt Gruppen bei der Ableitung und warnt vor breiten ACL-Gruppen in Verbindung mit engeren Regeln. Die Warnhinweise verlangen Prüfung. Wir haben den Quellcode gelesen, aber nicht ausgeführt.
Bewahre Konverterausgabe und Protokolle bei den Migrationsnachweisen auf. Bestimme je Warnung die betroffene effektive Gruppenkombination und Operation. Belege dann das freigegebene Ergebnis auf der aktualisierten Datenbank. Auch ein sauberes Konvertierungsprotokoll ersetzt keine Regressionstests für deine Regeln.
Leite daraus keine pauschale Anweisung ab, breite Grants zu löschen. Eine andere Rolle kann sie berechtigt benötigen. Prüfe die gesamte freigegebene Matrix, bevor du eine gemeinsame Gruppe änderst, einschließlich Nutzer, die sie über eine weitere Rolle erben.
Was zeigten die sechzehn lokalen Fälle?
Alle sechzehn lokalen Fälle lieferten die erwarteten Beobachtungen. Sie zeigen, wie Tests fehlende Einschränkungen, zusätzliche Grants und falschen Gesellschaftskontext unterscheiden. Sichtbarkeit wird außerdem von Wertauswahl und Beziehungskonsistenz getrennt. Diese Ergebnisse betreffen ein kleines Python-Modell. Sie sind keine Sicherheitsbewertung einer Odoo-Datenbank oder eines tatsächlichen Upgrades.
| Fall | Erwartet | Beobachtet |
|---|---|---|
| Eigener Datensatz im aktiven A | Erlauben | Erlaubt |
| Fremder Datensatz im aktiven A | Verweigern | Verweigert |
| B ist berechtigt, aber nicht aktiviert | B-Datensatz verweigern | Verweigert |
| B ist berechtigt und aktiviert | Eigenen B-Datensatz erlauben | Erlaubt |
| B ohne Mitgliedschaft aktivieren | Kontext zurückweisen | Kontextfehler |
| Breiten Gruppengrant ergänzen | Fremder A-Datensatz wird lesbar | Erlaubt |
| Breite Gruppe mit globaler Gesellschaftsregel | Inaktives B bleibt gesperrt | Verweigert |
| Globale Gesellschaftsregel weglassen | Fehlerhafte Konfiguration legt inaktives B offen | Erlaubt |
| Widersprüchliche globale Nur-A- und Nur-B-Regeln | Berechtigten A-Datensatz sperren | Verweigert |
| Geteilter Datensatz ohne Gesellschaft | Strenge Regel verweigert; ausdrückliche Freigaberegel erlaubt | Verweigert / erlaubt |
| Globale Einschränkung ohne Gruppengrant | Verweigern | Verweigert |
| Reine Leserolle im Modell | Lesen erlauben; Schreiben und Löschen verweigern | Erlaubt / verweigert / verweigert |
| Naive Konvertierung der alten gestuften Regel | Alte Verweigerung wird unbeabsichtigte Erlaubnis | Verweigert / erlaubt |
| B-Datensatz sichtbar bei aktueller Gesellschaft A oder B | Gesellschaftswert unterscheidet sich: 100,00 oder 120,00 | 100,00 / 120,00 |
| Sichtbarer A-Datensatz mit B-Datensatz verknüpft | Zugriff besteht; beispielhafte Beziehungsprüfung scheitert | Erlaubt / inkonsistent |
| Leere Eingabe für aktivierte Gesellschaften | Rückfall auf Mitgliedschaften A/B | B-Datensatz lesbar |
Lade das ausführbare Berechtigungsmodell und die aufgezeichneten Ergebnisse herunter. Mit Python ab Version 3.10 startest du es so:
python3 permission-model.pyDas Modell erhält effektive Gruppen als bereits aufgelöste Eingaben. Es implementiert weder Gruppenvererbung noch Odoo-Domänen, Feldrechte, Caches oder native Create-/Write-Hooks. Die Beziehungsprüfung ist bewusst nur ein kleiner Gleichheitsvergleich. Sie belegt nicht das Verhalten jedes teilbaren oder gesellschaftsabhängigen Felds in einem echten Modul.
Was gehört in die native Rollen- und Gesellschaftsmatrix?
Die native Matrix braucht ein freigegebenes Soll je relevanter Identität, Gesellschaftskontext und Operation sowie Nachweise aus dem aktualisierten System. Kombiniere normale erlaubte Arbeit mit verweigerten Zugriffen. Prüfe bei verbotenen Schreibversuchen den resultierenden Zustand neben der Fehlermeldung. Ein Screenshot eines fehlenden Menüs belegt die zugrunde liegende Operation nicht.
Die vorgeschlagene native Abnahmematrix beginnt vollständig mit NOT_RUN. Ihre Sollwerte sind zu prüfende oder zu ersetzende Beispiele. Trage Nutzer, effektive Gruppen, Build-Version, Einstiegspunkt, Datensatzkennungen, Gesellschaftskontext und Nachweise ein, bevor sie eine Releaseentscheidung begründet.
| Dimension | Benötigter Vergleich | Nachweis |
|---|---|---|
| Rolle | Gewöhnlicher Besitzer gegenüber freigegebenem breiterem Prüfer | Effektive Gruppen und erwartete Datensatzmenge je Identität |
| Gesellschaftsumfang | Nur A, aktives A/B und unberechtigte B-Auswahl | Genauer Kontext und Gesellschaft des Zieldatensatzes |
| Operation | Erlaubtes Lesen oder Schreiben gegenüber verbotener Änderung | Zurückgegebene Datensätze, Ergebniszustand und ausgebliebene verbotene Änderungen |
| Einstiegspunkt | Nutzeraktion und jede relevante Integration oder Hintergrundaufgabe | Tatsächliche Ausführungsidentität und aufgerufene Operation |
| Regelmigration | Altes freigegebenes Soll gegenüber gewünschtem neuen Soll | Konverterwarnung, geprüfte Änderung und beobachtetes natives Ergebnis |
| Geschäftskonsistenz | Richtiger Gesellschaftswert und erlaubte Verknüpfung | Wert- und Beziehungsnachweise getrennt von Sichtbarkeit |
Nutze direkte Datensatzkennungen zusätzlich zur normalen Navigation. Definiere das Soll für jeden Einstiegspunkt: Soll eine Suche keine fremden Daten liefern oder eine angeforderte Operation abweisen? Akzeptiere kein zu breites Ergebnis, nur weil die Oberfläche zusätzliche Zeilen ausblendet.
Führe destruktive Fälle nur auf kontrollierten Testdatensätzen in der Probenumgebung aus. Ergänze erlaubte Änderungen, damit eine alles blockierende Konfiguration nicht besteht. Der Leitfaden zu Geschäftszustandstests für Agenten erweitert dieses Nachweisprinzip auf vollständige Aufgaben, bei denen eine plausible Antwort den falschen Datensatz verdecken kann.
Warum Werte und Beziehungen nach erfolgreichem Zugriff prüfen?
Erfolgreicher Zugriff zeigt, dass die Identität die getestete Operation nach dieser Regel ausführen darf. Er belegt nicht automatisch den richtigen Gesellschaftswert oder eine passende Verknüpfung. Im Modell bleibt der B-Datensatz lesbar, obwohl A den Wert liefert. Für eine erlaubte Operation kann die gesonderte Beziehungsprüfung trotzdem fehlschlagen.
Der offizielle Multi-Company-Leitfaden bindet gesellschaftsabhängige Werte an die aktuelle Gesellschaft und beschreibt gesonderte Beziehungsprüfungen über _check_company_auto und check_company. Prüfe diese Mechanismen an den konkreten Modellen und Feldern deines Moduls.
Im Beispiel sind beide Gesellschaften lesbar. Mit A als aktueller Gesellschaft erscheint der erfundene Wert 100,00, mit B der Wert 120,00. Betrifft die Aufgabe B, kann ein erfolgreicher Abruf von 100,00 fachlich falsch sein. Erfasse die erwartete Gesellschaft neben dem Sollwert.
Wähle für Beziehungen eine erlaubte und eine verbotene gesellschaftsübergreifende Verknüpfung. Prüfe die Operation, die sie tatsächlich zuweist. Ein sichtbares Gesellschaftsfeld oder eine Zugriffsdomäne belegt nicht jede eigene Beziehungskontrolle. Der Audit-Leitfaden für eigene Odoo-Module behandelt die weitere Implementierungsprüfung.
Welche Nachweise sperren oder erlauben das Release?
Stoppe den betroffenen Migrationsumfang, wenn eine unerwartete Identität geschützte Daten erreicht, ein berechtigter Nutzer nötige Arbeit verliert oder der getestete Gesellschaftskontext unbelegt bleibt. Gib erst frei, wenn die vereinbarte Matrix auf dem vorgesehenen Build besteht, absichtliche Regeländerungen genehmigt und offene Konverterwarnungen konkret entschieden sind.
Erhalte Sollmatrix, effektive Gruppen und genaue Modulrevision zusammen mit den Beobachtungen. Eine bewusst breitere Prüferrolle kann richtig sein, braucht aber eine ausdrückliche Regeländerung. Eine alte Verweigerung ist nicht automatisch das richtige neue Soll; eine alte Erlaubnis ist nicht automatisch sicher.
Die QA-Checkliste vor dem Release ordnet diese Nachweise in die Launchentscheidung ein. Der Odoo-API-Architekturleitfaden behandelt weiterhin Hosting und Protokolle. Eine andere API-Route ersetzt keine native Rechteprüfung.
Für Wavects Software-Qualitätssicherung bringst du eine betroffene Rolle, zwei Gesellschaftskontexte und die Konvertierungsausgabe mit. Das erste nutzbare Ergebnis ist eine vereinbarte Erlauben-/Verweigern-Matrix mit reproduzierbaren nativen Nachweisen für diesen Umfang.