In diesem Beitrag
KI-generierte Odoo-Module: Geschäftsregeln im Audit prüfen
Eine Rabattfreigabe wirkt klein: Kennzeichen setzen und Freigebenden speichern. Unser absichtlich fehlerhaftes Beispiel genehmigt dabei ein storniertes Angebot, vertraut einer erfundenen Freigabeidentität und hinterlässt nach einem provozierten Fehler Teiländerungen. Die gewöhnliche Demonstration besteht trotzdem.
Prüfe ein KI-generiertes Odoo-Modul gegen freigegebene Geschäftsregeln und die genau installierte Odoo-Version. Reproduziere folgenschwere Fehler, kontrolliere die endgültigen Datensätze und verifiziere Korrekturen unabhängig. Ein bestandenes lokales Modell hilft beim Testentwurf. Native Nachweise für Installation, Berechtigungen, Transaktionen und Upgrade entscheiden weiterhin über den Einsatz.
Recherchestand: 5. November 2026. Wir haben offizielle Odoo-20-Quellen geprüft und dreizehn fiktive Freigabefälle ausgeführt. Beide Python-Beispiele wurden für diesen Artikel geschrieben. Sie sind weder Kundencode noch ein Benchmark eines KI-Werkzeugs. Kein Odoo-Addon wurde installiert, kein natives Upgrade ausgeführt. Alle vorgeschlagenen nativen Abnahmen bleiben NOT_RUN.
Welche Entscheidung soll das Modulaudit treffen?
Ein Modulaudit soll entscheiden, ob eine konkrete Anpassung genügend Nachweise für die Freigabe hat, eine begrenzte Reparatur braucht oder durch eine genehmigte einfachere Lösung ersetzt werden sollte. Beginne damit, was der Geschäftsbefehl ändern darf. Eine Codebewertung liefert weder fehlende Freigaberegeln noch die Befugnis, sie zu genehmigen.
Lass den Verantwortlichen die Anforderung an der aktuellen Konfiguration zeigen, bevor du eigenen Code erweiterst. Erfüllt ein unterstützter vorhandener Ablauf die Aufgabe, vergleiche ihn mit einem dauerhaft zu pflegenden Override. Das ist eine Prüfung an der installierten Version. Sie unterstellt nicht, dass jede eigene Freigabelogik unnötig ist.
Fixiere dann den Prüfumfang: Modulcommit, Odoo-Version und Edition, Abhängigkeiten, betroffene Datensätze und Ausführungsidentitäten. Nimm verhaltensrelevante Einstellungen dazu. Eine Branch-Prüfung ohne erforderliche Konfiguration kann genau den Weg übersehen, den das Unternehmen später nutzt.
Der allgemeine QA-Leitfaden für KI-generierten Code behandelt die breitere Produktionsreife. Hier ist eine deterministische Odoo-Anpassung die Prüfeinheit. Der Leitfaden zu Agenten-Geschäftszuständen prüft dagegen vollständige Agentenaufgaben und ihre Werkzeugauswahl.
Was soll das Freigabebeispiel tun?
Der Beispielbefehl darf die aktuelle Version eines Angebotsentwurfs freigeben, wenn die handelnde Identität für dessen Gesellschaft befugt ist und der Rabatt innerhalb einer erfundenen Delegationsgrenze liegt. Es protokolliert die vertrauenswürdige Identität einmal. Veraltete oder verbotene Entscheidungen müssen ohne Teilfreigabe scheitern, auch wenn erst ein späterer Eintrag im Stapel fehlschlägt.
Das fiktive Angebot Q-17 gehört zu Gesellschaft A, hat Version 3 und beginnt mit 5,00 % Rabatt. Nutzer 7 darf Rabatte von 0 % bis einschließlich 10,00 % freigeben. 10,01 % verlangen eine andere Entscheidung. Das sind Beispielregeln, keine Odoo-Standardwerte. Die Felder approval und approved_revision gehören zum Python-Modell.
| Regel | Erlaubtes Ergebnis | Gefordertes Fehlerverhalten |
|---|---|---|
| Befugnis und Gesellschaft | Die aktuell befugte Identität handelt innerhalb von A. | Fehlende Rolle oder unberechtigte Gesellschaft lässt den Datensatz unverändert. |
| Version und Lebenszyklus | Die geprüfte Version ist aktuell; das Angebot bleibt Entwurf. | Veraltete Version oder storniertes Angebot wird zurückgewiesen. |
| Delegationsgrenze | 10,00 % sind in der Beispielgrenze eingeschlossen. | 10,01 % dürfen diese Freigabe nicht erhalten. |
| Identitätsnachweis | Die Freigabe protokolliert den vertrauenswürdigen Nutzer 7. | Eine übergebene Bezeichnung darf ihn nicht durch Nutzer 99 ersetzen. |
| Wiederholte Auswahl | Eine Freigabe und ein Auditeintrag je Angebotsversion. | Wiederholung oder Doppelauswahl erzeugt keine zusätzliche Wirkung. |
| Stapelfehler | Der vereinbarte Stapel wird samt Auditnachweisen abgeschlossen. | Abgelehnter Eintrag oder provozierter Auditfehler hinterlässt keine Teiländerungen. |
Die Freigabe verändert hier ein Prüffeld. Sie bestätigt weder das Angebot noch erstellt sie eine Lieferung oder Buchung. Diese Grenze gehört zur Definition von Erfolg. Führt das echte Modul eine spätere Geschäftsaktion aus, ergänze deren Befugnisse und geforderten Endzustand.
Kläre umstrittene Regeln vor den Sollwerten. Der Leitfaden zu widersprüchlichen Geschäftsregeln behandelt diese Zuständigkeit. Ein Prüfer kann nicht aus einer Funktion, die 10,00 % akzeptiert, ableiten, dass diese Grenze fachlich richtig ist.
Welche Fehler zeigt die kommentierte Prüfung?
Die Prüfung zeigt fehlende Geschäftsvoraussetzungen, eine nicht vertrauenswürdige Freigabeidentität und Änderungen nach einer unvollständigen Aktion. Wiederholungen erzeugen außerdem einen weiteren Auditeffekt. Jeder Befund verbindet eine konkrete Anweisung mit einem gescheiterten Regeltest. Das trägt mehr zur Releaseentscheidung bei als eine allgemeine Risikozahl für „KI-generierten Code“.
Das fehlerhafte Beispiel enthält diese hier auf die Reihenfolge verkürzte Sequenz:
quote["approval"] = "approved"
quote["approved_revision"] = expected_revisions[key]
quote["approved_by"] = claimed_approver or actor["uid"]
if key == fail_audit_for:
raise InjectedAuditFailure(key)
store["audits"].append({
"quote": key,
"revision": expected_revisions[key],
"actor": quote["approved_by"],
})Diese Sequenz prüft nicht, ob die Identität den aktuellen Datensatz freigeben darf. Odoos Hinweise zu öffentlichen Methoden behandeln übergebene Datensätze und Parameter als nicht vertrauenswürdig. CRUD-Rechteprüfungen belegen nicht jede Geschäftsvoraussetzung. Prüfe die empfangende Methode, nicht nur ihren sichtbaren Button.
| Befund | Geschäftsfolge im Modell | Zu prüfende Korrektur |
|---|---|---|
| Keine Prüfung aktueller Befugnis und Datensätze | Unberechtigte Identität oder Gesellschaft erhält eine Freigabe. | Vertrauenswürdige Identität und Ziel vor der Änderung prüfen. |
| Keine Voraussetzungen für Version, Status oder Grenze | Veraltete, stornierte oder zu hohe Anfrage wird genehmigt. | Freigegebene Regeln mit aktuellen Datensatzwerten vergleichen. |
| Aufrufer bestimmt protokollierten Freigebenden | Audit nennt Nutzer 99 statt Nutzer 7. | Zuordnung aus der vertrauenswürdigen Ausführungsidentität ableiten. |
| Jede Auswahl erzeugt einen weiteren Effekt | Wiederholung oder doppelter Eintrag erzeugt zwei Auditeinträge. | Eine bereits abgeschlossene Freigabe dieser Version erkennen. |
| Änderung vor Fehler ohne atomare Grenze | Gescheiterter Audit-Eintrag hinterlässt Freigabe oder Teilstapel. | Vereinbartes Alles-oder-nichts-Ergebnis an der echten Umsetzung belegen. |
Die korrigierte Python-Fassung prüft die Auswahl und ändert zunächst eine Kopie, bevor sie den Modellzustand ersetzt. Das modelliert das Soll, implementiert aber keine Odoo-Transaktionen. Die offiziellen Programmierrichtlinien erläutern die Transaktionszuständigkeit des Frameworks und den Prüfbedarf unbegründeter manueller Commits. Ausnahmsweise ausdrücklich selbst verwaltete Cursor brauchen eigene Begründung.
Im kommentierten Befundprotokoll findest du zu jedem Fehler einen Reproduktionsfall. Die Odoo-20-Tests zur Gesellschaftstrennung behandeln die versionsabhängige Rechteumstellung. Eine allgemeine alte ACL-Checkliste liefert dafür nicht genug Kontext.
Was änderte sich in den dreizehn Regeltests?
Die fehlerhafte Fassung verletzt elf von dreizehn festen Erwartungen. Die korrigierte Fassung erfüllt alle dreizehn. Beide bestehen normale Freigabe und exakte Obergrenze. Damit wird sichtbar, weshalb eine erfolgreiche Demonstration andere Fehler verdecken kann. Die Zahlen betreffen konstruierte Beispiele und sind keine Fehlerquote KI-generierter Odoo-Module.
| Fall | Fehlerhafte Fassung | Korrigierte Fassung |
|---|---|---|
| Normale Freigabe mit 5,00 % | Genehmigt; ein Auditeintrag | Genehmigt; ein Auditeintrag |
| Exakte Grenze von 10,00 % | Genehmigt; ein Auditeintrag | Genehmigt; ein Auditeintrag |
| Anfrage mit 10,01 % | Fälschlich genehmigt | Abgelehnt; unverändert |
| Identität ohne Freigabebefugnis | Fälschlich genehmigt | Abgelehnt; unverändert |
| Datensatz gehört zum unberechtigten B | Fälschlich genehmigt | Abgelehnt; unverändert |
| Prüfung nennt Version 3, Datensatz hat Version 4 | Fälschlich gegen Version 3 genehmigt | Abgelehnt; unverändert |
| Angebot storniert | Freigabekennzeichen trotzdem gesetzt | Abgelehnt; unverändert |
| Dasselbe Angebot zweimal in einer Anfrage | Zwei Auditeinträge | Ein Auditeintrag |
| Dieselbe Freigabe zweimal aufgerufen | Zwei Auditeinträge | Ein Auditeintrag |
| Aufrufer übergibt Freigebenden 99 | Nennt Nutzer 99 | Nennt vertrauenswürdigen Nutzer 7 |
| Auditfehler nach Freigabezuweisung | Kennzeichen bleibt; kein Auditeintrag | Keine Änderungen |
| Zweiter Stapeldatensatz gehört zum unberechtigten B | Beide genehmigt | Keiner geändert |
| Zweiter Audit-Schreibvorgang scheitert | Beide genehmigt; nur ein Auditeintrag | Keiner geändert |
Lade das ausführbare Freigabebeispiel und die vollständigen Soll- und Istzustände herunter. Speichere die Python-Datei und starte:
python3 approval-review-model.pyDas Skript nutzt die Python-Standardbibliothek und Dezimalvergleiche für die erfundene Prozentregel. Es importiert kein Odoo und greift auf kein Netzwerk zu. Die Sollzustände folgen unabhängig von beiden Funktionen aus den Regeln. Die Ausgabe enthält Fehler und endgültige Freigabefelder. Eine Exception allein kann eine Teiländerung dadurch nicht als korrekt erscheinen lassen.
Das Modell prüft keine gleichzeitigen nativen Anfragen. Genehmigen zwei Aufrufer dieselbe Version parallel, kann die echte Methode weitere Schutzmaßnahmen brauchen. Der Artikel zur n8n-Wiederaufnahme behandelt externe Auftragserstellung. Der wiederholte Auditeffekt dieses Modells belegt keine Connector-Idempotenz.
Was muss am echten Odoo-Modul geprüft werden?
Prüfe echte Einstiegspunkte und betroffene Datensätze auf dem tatsächlichen Build, bevor du Modellschlüsse auf Odoo überträgst. Untersuche Overrides und Abhängigkeiten und führe freigegebene Geschäftsfälle über die empfangenden Methoden aus. Bestätige jede Ausführungsidentität. Eine isoliert korrekte Funktion kann weiterhin falsch in die Anwendung eingebunden sein.
| Bereich | Prüffrage | Benötigter Nachweis |
|---|---|---|
| Einstiegspunkte | Erreichen Button, API-Aufruf und Automatisierung dasselbe Verhalten? | Freigegebene Identität und Endzustandsprüfung je relevantem Weg. |
| Abhängigkeiten | Deklariert das Manifest die verwendeten Module? | Reproduzierbare Installation aus den deklarierten Abhängigkeiten. |
| Overrides | Warum wird jedes Basisverhalten ersetzt oder erweitert? | Regressionstests belegen weiter funktionierende Standardabläufe. |
| Gesellschafts- und Feldverhalten | Nutzt der Befehl vorgesehenen Datensatz, Gesellschaft und Wert? | Native Rollen-/Kontextnachweise und repräsentative Feldprüfungen. |
| Fehler und Parallelität | Was bleibt nach Unterbrechung oder paralleler Freigabe? | Datensätze und Auditeffekte bei kontrollierten Fehlerabläufen. |
| Vorhandene Daten | Was geschieht mit Angeboten aus einer älteren Modulversion? | Freigegebenes Upgrade-Soll und beobachtete Datensätze nach der Probe. |
Das vorgeschlagene native Abnahmepaket enthält diese Freigabestufen und die Geschäftsfälle. Es beginnt mit NOT_RUN und ausstehender Regelgenehmigung. Ersetze Beispielerwartungen durch freigegebene Regeln. Trage genaue Identitäten und Versionen ein und ergänze echte Nachweise vor einem bestandenen Ergebnis.
Vergleiche jeden Override mit dem Standardverhalten. Bei einer unbegründeten Ersetzung musst du erst herausfinden, was entfernt wurde. Braucht das Modul nur eine zusätzliche Entscheidungskontrolle, prüfe eine engere Erweiterung statt eines komplett ersetzten Ablaufs. Belege diese Wahl mit den betroffenen Standardfällen.
Wie prüfst du Installation und Upgrade getrennt?
Behandle Installation, Upgrade und Laufzeitverhalten als eigene Freigabestufen. Eine Neuinstallation kann fehlende Abhängigkeiten zeigen. Eine Probe mit vorhandenen Daten prüft frühere Datensätze und Einstellungen. Keine davon beweist, dass die richtigen Geschäftstests liefen. Binde den Bericht an genaue Modulrevision, Zielumgebung und ausgewählte Testfälle.
Odoos Testdokumentation verlangt importierte Testmodule und erklärt, wie Aktivierung und Auswahl ihre Ausführung bestimmen. Verlange Runner-Ausgaben mit den vorgesehenen Tests. Ein grüner Befehl ohne relevante Fälle lässt deren Verhalten ungeprüft.
Der Leitfaden für angepasste Datenbankupgrades trennt Installation auf leerer Datenbank, Installation auf aktualisierten Daten und Laufzeitprobe. Unser Python-Lauf liefert keinen dieser nativen Nachweise.
Für die Freigabeanpassung brauchst du ein älteres Angebot ohne ausgefüllte neue Prüffelder, ein bereits genehmigtes Angebot mit verändertem Inhalt und einen beim Upgrade noch offenen Prüffall. Entscheide ihren Zielzustand vor der Probe. Ein Default, der einen alten Datensatz genehmigt aussehen lässt, ist eine Geschäftsentscheidung.
Halte einen kontrollierten Wiederherstellungsplan für die Probe bereit. Code zurückzusetzen belegt nicht, dass Datenänderungen rückgängig sind. Der Leitfaden zur Migrationsabstimmung behandelt den breiteren Soll-Ist-Vergleich.
Was muss die Auditübergabe enthalten?
Jede Releaseentscheidung muss auf eine freigegebene Regel und reproduzierbare Nachweise zurückführbar sein. Notiere für jeden Blocker Revision, Reproduktion und Geschäftsfolge. Ergänze Korrektur und unabhängigen Nachtest. Unausgeführte Prüfungen bleiben sichtbar. Stilvorschläge allein beantworten nicht, ob ein Angebot unberechtigt freigegeben werden kann.
Das Befundprotokoll unterscheidet bestätigte lokale Regelverletzungen von offenen nativen Fragen. Behalte diese Trennung im echten Audit. „Das Modell lehnt veraltete Freigaben ab“ und „die eingesetzte Odoo-Methode lehnt sie mit diesen Identitäten ab“ sind unterschiedliche Nachweise.
Trenne Implementierungskorrektur und Regelgenehmigung. Der Prüfer kann belegen, dass eine Funktion 10,00 % durchsetzt. Der Verantwortliche entscheidet, ob dies die gewünschte Delegation ist. Ändert sich die Regel während des Audits, passe die Sollwerte an und wiederhole betroffene Fälle.
Die QA-Checkliste vor dem Release liefert den weiteren Launchkontext. Der allgemeine Audit-Leitfaden für KI-erstellte Software beschreibt ein breiteres Mandat. Die Modulprüfung sollte ihren engeren, prüfbaren Umfang behalten.
Wann würden wir freigeben, reparieren oder entfernen?
Gib eine Anpassung nur in dem Umfang frei, den genehmigte native Nachweise tragen. Repariere belegte Regelverletzungen und prüfe betroffene Abläufe erneut. Erwäge eine Entfernung, wenn eine genehmigte unterstützte Alternative den Bedarf erfüllt und vorhandene Daten berücksichtigt sind. Eine überzeugende Vorführung entscheidet keine dieser Fragen.
Wir würden mit einem folgenreichen Befehl, seinem echten Einstiegspunkt und je einem erlaubten und verbotenen Fall beginnen. Ergänze Fehlerfälle, die falsche Geschäftsdatensätze hinterlassen können. So erhält das Audit eine erste konkrete Entscheidung, bevor es jede Datei des Repositorys untersucht.
Für Wavects Software-Qualitätssicherung bringst du Modulcommit, installierte Version und eine genehmigungsfähige Geschäftsregel mit. Der nutzbare Befund enthält einen reproduzierbaren Test und eine klare native Freigabestufe, gefolgt vom Nachweis der vereinbarten Korrektur.