--- title: "Odoo 20: Rechte und Gesellschaftstrennung prüfen" canonical: https://wavect.io/de/blog/odoo-20-company-access-migration-tests/ language: de description: "Prüfe Odoo-20-Rechte mit einer Rollen- und Gesellschaftsmatrix. Vergleiche sechzehn lokale Regelfälle, prüfe Konverterwarnungen und belege den nativen Zugriff." image: "https://wavect.io/img/blog/headers/header_odoo-20-company-access-migration-tests.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo-20-Rechtemigration: Gesellschaftstrennung prüfen [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 Min. Lesezeit · 5. November 2026 Zuletzt geprüft 5. November 2026 [**Weiter**](/de/blog/odoo-email-pdf-quotation-review/) TL;DR Nimm die Odoo-20-Rechtemigration gegen eine freigegebene Rollen- und Gesellschaftsmatrix ab. Prüfe erlaubte und verbotene Operationen, kombinierte Grants und globale Einschränkungen. Erfasse aktivierte sowie aktuelle Gesellschaften und teste Werte gesondert. Sechzehn lokale Python-Fälle illustrieren Fehler im fiktiven Regelmodell. Die native Odoo-Matrix bleibt NOT_RUN, bis sie auf dem aktualisierten Build ausgeführt wurde. 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](https://github.com/odoo/documentation/blob/20.0/content/developer/reference/backend/security.rst) 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](https://github.com/odoo/documentation/blob/19.0/content/developer/reference/backend/security.rst) 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](/de/blog/odoo-migration-acceptance-reconciliation/) 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änkung ``` Unsere 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](https://github.com/odoo/odoo/blob/20.0/odoo/addons/base/models/ir_access.py) 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](https://github.com/odoo/odoo/blob/20.0/odoo/orm/environments.py) 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](https://github.com/odoo/odoo/blob/20.0/odoo/upgrade_code/19.4-00-ir-access.py) 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](/downloads/odoo-20-company-access-migration-tests/permission-model.py) und die [aufgezeichneten Ergebnisse](/downloads/odoo-20-company-access-migration-tests/model-results.json) herunter. Mit Python ab Version 3.10 startest du es so: ``` python3 permission-model.py ``` Das 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](/downloads/odoo-20-company-access-migration-tests/native-acceptance.json) 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](/de/blog/odoo-ai-agent-business-state-tests/) 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](https://github.com/odoo/documentation/blob/20.0/content/developer/howtos/company.rst) 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](/de/blog/ai-generated-odoo-module-audit/) 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](/de/software-development-guide/software-qa-checklist-before-launch/) ordnet diese Nachweise in die Launchentscheidung ein. Der [Odoo-API-Architekturleitfaden](/de/blog/odoo-erp-api-integration-limits-2026/) behandelt weiterhin Hosting und Protokolle. Eine andere API-Route ersetzt keine native Rechteprüfung. Für Wavects [Software-Qualitätssicherung](/de/services/software-quality-assurance/) 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. ## Häufige Fragen zur Odoo-20-Rechtemigration ### Belegt ein verborgenes Menü, dass der Zugriff verweigert wird? Nein. Die Abnahme betrifft Datensatz und Operation, die eine Identität verwenden darf. Prüfe normalen Nutzerweg und relevanten direkten Einstieg mit kontrollierten Daten. Erfasse Rückgabedaten und Ergebniszustand. Ein Menüscreenshot dokumentiert die Oberfläche, ersetzt aber keinen Nachweis, dass die geschützte Operation die freigegebene Regel eingehalten hat. ### Erzwingt eine leere allowed_company_ids-Liste Zugriff auf keine Gesellschaft? Nein. In der untersuchten Environment-Implementierung von 20.0 fällt eine leere Liste auf die Gesellschaften des Nutzers zurück. Definiere einen ausdrücklichen erlaubten Kontext und prüfe ihn. Braucht deine Anwendung einen Zustand ohne Zugriff, beschreibe und verifiziere dieses Regelergebnis. Verlasse dich dafür nicht auf eine leere Kontextliste. ### Wie werden Datensätze ohne Gesellschaft abgenommen? Entscheide, welche Datensätze bewusst geteilt werden und welche einen Besitzer benötigen. Das Modell prüft eine strenge Gesellschaftsregel und eine ausdrückliche Freigabe geteilter Daten mit verschiedenen Ergebnissen. Nutze Vertreter jeder genehmigten Kategorie samt Verknüpfungen. Ein fehlender Gesellschaftswert darf sensible Daten nicht stillschweigend zur gemeinsamen Nutzung freigeben. ### Wie prüfst du geerbte und zusätzliche Gruppen? Prüfe die effektiven Gruppen der Identität, einschließlich über andere Rollen erlangter Gruppen. Das Modell bekommt diese Menge als Eingabe und berechnet keine Vererbung. Teste tatsächliche Nutzerkombinationen, besonders eine enge Rolle zusammen mit einer breiteren Prüferrolle. Einzeltests beider Gruppen können ihre kombinierte Wirkung übersehen. ### Beweisen die sechzehn Modellfälle eine sichere echte Datenbank? Nein. Sie demonstrieren benannte Regel- und Kontextergebnisse in einem kleinen Python-Programm mit Standardbibliothek. Sie führen weder Odoo noch native Domänen oder eigene Methoden aus. Nutze die Gegenbeispiele für bessere Abnahmen und führe anschließend die separate NOT_RUN-Matrix auf dem genauen aktualisierten Build mit freigegebenen Geschäftsregeln aus. ### Was gilt für Dienstkonten und geplante Aufgaben? Erfasse Identität und Gesellschaftskontext jeder Automatisierung und teste ihre freigegebenen Operationen. Ein Administrator-Rundgang ersetzt diesen Ausführungsweg nicht. Verwende vorgesehene Datensätze sowie einen kontrollierten Datensatz, den die Aufgabe nicht berühren darf. Prüfe die Änderungen. Breite Zugangsdaten benötigen eine ausdrückliche fachliche Begründung und einen passenden Abnahmeumfang. ### Muss jede Abweichung zu Odoo 19 das Release stoppen? Eine ungeklärte Abweichung sollte den betroffenen Umfang stoppen. Eine beabsichtigte Regelkorrektur kann freigegeben werden, etwa das Beheben eines alten zu breiten Grants. Dokumentiere altes Soll, gewünschte neue Regel und genehmigenden Verantwortlichen. Vergleiche das aktualisierte System mit diesem freigegebenen Ziel und nicht nur mit früherem Verhalten. QA und Produktionsreife ## Weiterlesen Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware. [Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/) - [README ZIP Schadsoftware: Was deckt deine Freigabe ab?](/de/blog/readme-zip-malware-install-review/) - [KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen](/de/blog/ai-generated-odoo-module-audit/) - [Odoo-Migration abnehmen: Datensätze und Salden abgleichen](/de/blog/odoo-migration-acceptance-reconciliation/) - [Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen](/de/blog/odoo-ai-agent-business-state-tests/) - [Odoo 19 auf 20: Was musst du bei KI neu abnehmen?](/de/blog/odoo-19-20-ai-upgrade-readiness/) [Vorheriger Artikel**Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen**](/de/blog/odoo-ai-agent-business-state-tests/) [Nächster Artikel**Odoo 19 auf 20: Was musst du bei KI neu abnehmen?**](/de/blog/odoo-19-20-ai-upgrade-readiness/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 Min. Lesezeit · 5. November 2026 Zuletzt geprüft 5. November 2026 [**Weiter**](/de/blog/odoo-email-pdf-quotation-review/)