Automatische Aktionen in OpenBiz
## Was sind automatische Aktionen?
Automatische Aktionen (englisch automated actions, technisch `base.automation`) sind Regeln, mit denen OpenBiz bei bestimmten Ereignissen oder Zeitbedingungen ohne weiteres Zutun Operationen ausführt. Typische Anwendungsfälle sind: ein Verkaufsleiter erhält automatisch eine E‑Mail, sobald ein Lead einen bestimmten Umsatzwert überschreitet; Aufgaben werden sieben Tage nach dem letzten Update archiviert; ein Kontakt wird automatisch erstellt, wenn ein Lead in eine Opportunity umgewandelt wird; nach der Bestätigung eines Auftrags wird eine Folgeaktivität beim verantwortlichen Mitarbeiter eingeplant.
Die Funktion basiert auf dem Standardmodul `base_automation`, das fester Bestandteil jeder OpenBiz Installation ist.
Zugriff in OpenBiz
Technischen Einstellungen:
1. Entwicklermodus aktivieren – unter Einstellungen → Entwicklertools → Entwicklermodus aktivieren (oder via URL‑Parameter `?debug=1`).
2. Menüpfad: Einstellungen → Technisch → Automatisierung → Automatische Aktionen.
3. Alternativ kann direkt aus einem beliebigen Formular heraus über das Entwicklermenü (Käfer‑Symbol oben rechts) der Eintrag Automatisierungen verwalten geöffnet werden — der passende Modellkontext ist dann bereits vorausgewählt.
Für den produktiven Einsatz empfiehlt es sich, einer dedizierten Benutzergruppe (z. B. internen Admins) Zugriff auf die technischen Einstellungen zu geben, statt den Entwicklermodus dauerhaft für alle User einzuschalten.
Aufbau einer automatischen Aktion
Jede Regel setzt sich aus vier Kernelementen zusammen:
Modell – das Datenmodell, auf das die Regel wirkt (z. B. `sale.order`, `res.partner`, `crm.lead`, `account.move`). Wenn Sie die Konfiguration aus einem Formular heraus öffnen, ist das Modell vorbelegt.
Auslöser (Trigger) – das Ereignis, das die Aktion startet. Sechs Triggertypen stehen zur Verfügung (siehe unten).
Anwenden auf – eine Domain‑Filterbedingung, die einschränkt, auf welche Datensätze des Modells die Regel überhaupt angewandt wird. Die Eingabe erfolgt im gleichen Stil wie die Filter in Listenansichten (Feld → Operator → Wert).
Auszuführende Aktion – die konkrete Operation, die ausgeführt wird. Acht Aktionstypen sind verfügbar.
Die sechs Auslösertypen
### Bei Erstellung
Die Aktion läuft, sobald ein neuer Datensatz erstmals gespeichert wird. Ideal für Initialisierungen, z. B. Standardwerte setzen oder Willkommens‑E‑Mails versenden.
### Bei Aktualisierung
Die Aktion läuft, wenn ein bestehender Datensatz bearbeitet und gespeichert wird. Über das Feld Auslösefelder (Trigger Fields) lässt sich festlegen, dass nur Änderungen an bestimmten Feldern die Aktion starten sollen — alle anderen Updates werden ignoriert.
Zusätzlich lassen sich Vor‑Update‑Domain und Apply on kombinieren, um Zustandsübergänge exakt abzubilden. Beispiel: Aktion soll nur laufen, wenn zum ersten Mal eine E‑Mail‑Adresse gesetzt wird. Dafür Before Update Domain = „Email ist nicht gesetzt" und Apply on = „Email ist gesetzt".
### Bei Erstellung und Aktualisierung
Kombination der beiden vorherigen Trigger: die Aktion läuft sowohl beim ersten Speichern als auch bei jeder nachfolgenden Änderung.
### Bei Löschung
Die Aktion läuft, wenn ein Datensatz gelöscht wird. In der Praxis selten eingesetzt, da archivieren (`active = False`) in der Regel dem harten Löschen vorgezogen wird.
### Basierend auf Formularänderung
Die Aktion läuft bereits während der Benutzer das Formular bearbeitet — noch bevor gespeichert wird. Dieser Trigger reagiert nur auf Änderungen, die direkt im Frontend durch einen Benutzer gemacht werden; programmatische Änderungen (etwa durch andere Module) lösen ihn nicht aus. Wichtig: Dieser Trigger funktioniert ausschließlich mit der Aktion Python‑Code ausführen, erfordert also Entwicklerkenntnisse.
### Basierend auf Zeitbedingung
Die Aktion läuft, sobald ein Datum oder Datum‑/Zeitfeld einen bestimmten Zeitpunkt erreicht. Sie geben ein Trigger‑Datumsfeld an (z. B. `date_deadline` oder `create_date`) und einen Versatz in Minuten/Stunden/Tagen/Monaten davor oder danach. Ausführung erfolgt über den Cronjob `ir_cron_base_automation_check` — prüfen Sie, dass dieser Cron aktiv ist und sinnvoll getaktet läuft (Standard: stündlich).
Beispiele: „7 Tage nach letzter Aktualisierung archivieren", „3 Tage vor Fälligkeit Erinnerungsmail", „30 Minuten nach Abschluss Follow‑up‑Aktivität anlegen".
Anwenden auf (Filter)
Hier definieren Sie, welche Datensätze von der Regel betroffen sind. Die Syntax entspricht den bekannten OpenBiz‑Domains. Beispiele:
- Nur Verkaufsaufträge über CHF 10'000: `amount_total >= 10000`
- Nur Leads aus der Schweiz: `country_id.code = CH`
- Nur Rechnungen im Status „Entwurf": `state = draft`
Lassen Sie das Feld leer, gilt die Regel für alle Datensätze des Modells. Gerade im Produktivbetrieb sollten Sie immer einen expliziten Filter setzen, damit eine Regel nicht versehentlich auf Altbestände angewandt wird.
Die acht Aktionstypen
### Python‑Code ausführen
Führt beliebigen Python‑Code im Server‑Kontext aus. Die verfügbaren Variablen (u. a. `records`, `record`, `env`, `user`, `model`, `log`, `Warning`) werden direkt im Reiter Python Code bzw. Hilfe aufgelistet. Mit `Available on the Website` zusammen mit einem Website Path lässt sich die Aktion auch über eine URL auf der Website triggern.
Beispiel:
```python
for rec in records:
if rec.amount_total > 50000:
rec.message_post(body="Grossauftrag – bitte manuell prüfen.")
```
### Neuen Datensatz erstellen
Legt einen neuen Eintrag auf einem beliebigen Modell an. Über Ziel‑Modell kann auch ein anderes Modell angesprochen werden als das der Regel. Über Link Field wird der auslösende Datensatz mit dem neu erzeugten verknüpft. Klassischer Einsatz: aus einer gewonnenen Opportunity wird automatisch ein Kontakt oder ein Verkaufsauftragsentwurf erzeugt.
### Datensatz aktualisieren
Schreibt Werte in Felder des auslösenden Datensatzes (oder eines verknüpften Datensatzes via Ziel‑Modell und Link Field). Einfachster und am häufigsten verwendeter Aktionstyp.
### Mehrere Aktionen ausführen
Verkettet mehrere andere Server‑Aktionen, die nacheinander abgearbeitet werden. Wählt man diesen Typ, werden die Unteraktionen über die Registerkarte Child Actions angelegt. Nützlich, wenn ein Ereignis mehrere Dinge gleichzeitig auslösen soll: Mail senden, Feld setzen, Aktivität anlegen.
### E‑Mail senden
Versendet eine vorkonfigurierte E‑Mail‑Vorlage (`mail.template`). Die Vorlage wählt man aus oder legt sie direkt aus der Aktion heraus neu an. Die Variablen in der Vorlage (`{{ object.name }}` usw.) werden beim Versand im Kontext des auslösenden Datensatzes aufgelöst.
### Follower hinzufügen
Fügt dem Datensatz automatisch Follower hinzu — entweder konkrete Benutzer oder Kontakte aus einem Feld des Datensatzes (z. B. Verantwortlicher). Nützlich, um sicherzustellen, dass bestimmte Personen immer über Chatter‑Nachrichten zu bestimmten Datensätzen informiert werden.
### Nächste Aktivität erstellen
Legt eine Aktivität (Anruf, Termin, To‑Do) im Aktivitäten‑Framework an. Über Activity User Type bestimmen Sie, wem die Aktivität zugewiesen wird:
- Spezifischer Benutzer – fester User.
- Generischer Benutzer aus Datensatz – z. B. der Verantwortliche (`user_id`) des auslösenden Datensatzes.
Typischer Use Case: Nach Umwandlung eines Leads in eine Opportunity automatisch einen Anruf in drei Tagen beim Vertriebsverantwortlichen einplanen.
### SMS versenden
Sendet eine SMS an einen Kontakt, der mit dem Datensatz verknüpft ist (z. B. `partner_id`). Voraussetzung ist die Konfiguration eines SMS‑Anbieters (OpenBiz IAP oder ein Drittanbieter‑Modul). Mit Log as Note wird die gesendete Nachricht zusätzlich im Chatter protokolliert.
Praxisbeispiele
Mahnwesen‑Erinnerung: Modell `account.move`, Trigger Basierend auf Zeitbedingung auf Feld `invoice_date_due`, Versatz +7 Tage, Filter `payment_state = not_paid`, Aktion E‑Mail senden mit Mahnvorlage.
Grossauftrags‑Benachrichtigung: Modell `sale.order`, Trigger Bei Erstellung und Aktualisierung mit Trigger Field `amount_total`, Filter `amount_total > 50000`, Aktion Mehrere Aktionen mit zwei Child Actions: Follower hinzufügen (Verkaufsleiter) und Aktivität anlegen.
Lead‑Zuweisung nach Region: Modell `crm.lead`, Trigger Bei Erstellung, Filter `country_id.code = CH`, Aktion Datensatz aktualisieren → Feld `user_id` auf den Schweizer Vertriebsmitarbeiter setzen.
Auto‑Archivierung inaktiver Partner: Modell `res.partner`, Trigger Basierend auf Zeitbedingung auf Feld `write_date`, Versatz +365 Tage, Filter z. B. `sale_order_count = 0`, Aktion Datensatz aktualisieren → `active = False`.
Hinweise zum produktiven Betrieb
Performance: Regeln mit Trigger Bei Aktualisierung ohne eingeschränkte Trigger Fields laufen bei jeder Änderung des Datensatzes — auch bei technischen Feldern. Grenzen Sie die auslösenden Felder immer so eng wie möglich ein.
Endlosschleifen: Eine Aktion, die selbst Felder ändert, kann ihre eigene Regel erneut triggern. Verwenden Sie Before Update Domain + Apply on, um Zustandsübergänge sauber abzugrenzen, oder bauen Sie im Python‑Code Abbruchbedingungen ein (`if not rec.flag: ...`).
Testen: Es gibt keinen „Trockenlauf". Testen Sie neue Regeln grundsätzlich auf einer Staging‑Datenbank. Ein Duplikat einer Kundendatenbank ist schnell erstellt und spart im Zweifel viel Aufwand.
Cronjob prüfen: Für zeitbasierte Trigger muss der Cron `ir_cron_base_automation_check` aktiv sein. Unter Einstellungen → Technisch → Automatisierung → Geplante Aktionen kontrollieren.
Wartung und Dokumentation: Geben Sie jeder Regel einen sprechenden Namen („CRM: Lead Schweiz → Vertrieb DE zuweisen" statt „Neue Regel 1"). Automatische Aktionen sind sonst im Betrieb schwer rückverfolgbar, wenn Verhalten unerwartet auftritt.
Migration: Automatische Aktionen werden bei Datenbank‑Migrationen auf neue OpenBiz‑Versionen nicht automatisch mit übernommen, wenn sich Feldnamen ändern. Nach jeder Migration Regeln durchgehen und Triggerfelder/Domains validieren.
Erweiterungen: Community Automation Addons
Das OCA‑Repository [OCA/automation](https://github.com/OCA/automation/tree/16.0) stellt unter anderem das Modul `automation_oca` zur Verfügung. Es erweitert das Konzept um mehrstufige Workflows mit aufeinander aufbauenden Schritten (ähnlich Marketing Automation, aber für beliebige Modelle). Anwendungsfälle sind etwa Lead‑Nurturing‑Kampagnen oder Warenkorb‑Abbruch‑Erinnerungen mit mehreren zeitversetzten Schritten. Für einfache Regeln bleibt `base_automation` die richtige Wahl; wenn Sie sequentielle Mehrschritt‑Prozesse benötigen, lohnt der Blick auf `automation_oca`.