Automatische Statuswechsel

FHZuletzt geändert 30. August 2026 · Franzi Halbhuber 3 min

Projekte können ihren Status von selbst wechseln — etwa damit ein Angebot nach zwei Wochen ohne Reaktion als überfällig erscheint und beim zuständigen Anwender als ToDo auftaucht, statt unbemerkt liegen zu bleiben.

Wie die Automatik funktioniert

Der Wechsel ist kein Ereignis, das beim Speichern ausgelöst wird, sondern ein Programm, das in regelmäßigen Abständen alle Projekte durchsieht und die fälligen umstellt. Konfiguriert wird es nicht an einer zentralen Stelle, sondern am Zielstatus: Im Tab Admin eines Status steht im Feld Aktionen, unter welcher Bedingung Projekte in genau diesen Status wandern sollen.

Abbildung 1: Das Feld „Aktionen" im Tab Admin eines Status

Eine Zeile beschreibt eine Regel, mehrere Zeilen mehrere Regeln. Der Aufbau ist immer derselbe:

<Zeitart>:<Zeitraum>:status=<Name des Zielstatus>

Der Zielstatus wird über seinen technischen Namen angesprochen, nicht über seinen Titel. Wird der Name eines Status geändert, laufen alle Regeln ins Leere, die ihn nennen — deshalb lässt sich der Name nach dem Anlegen auch nicht mehr ändern.

Die vier Zeitarten

Sie unterscheiden sich darin, worauf sie sich beziehen — und, praktisch noch wichtiger, ob sie einen verpassten Tag nachholen.

Zeitart	Bezugspunkt	Verhalten
change	Der letzte Statuswechsel des Projektes	Erfasst alles, was älter ist als der Zeitraum — holt nach.
inactivity	Ein Datumsfeld des Projektes	Erfasst alles, was fällig geworden ist — holt nach.
validity	Das Gültigkeitsdatum des Projektes	Greift an genau einem Tag.
resubmission	Das Wiedervorlagedatum des Projektes	Greift an genau einem Tag.

Bei validity und resubmission ist ein verpasster Tag endgültig verpasst: Läuft das Programm an diesem Tag nicht, findet der Wechsel nicht mehr statt. Bei change und inactivity wird er beim nächsten Lauf nachgeholt.

Zwei Beispiele

Angebot ohne Reaktion. Projekte im Status „Angebot erstellt" wandern nach 14 Tagen ohne Statuswechsel automatisch in einen Überfällig-Status. So durchlaufen alle Projekte die vorgesehenen Stationen, statt in einem Status zu verharren:

change:-14day:status=offer_created_todo

Angebot läuft ab. Sieben Tage vor Ablauf des Gültigkeitsdatums wechselt das Projekt in einen Status, der auf das nahende Fristende hinweist:

validity:+7day:status=offer_submitted_todo

Was sich zusätzlich steuern lässt

Hinter dem Zielstatus können weitere Angaben stehen, jeweils durch Doppelpunkt getrennt. Die wichtigsten:

Angabe	Wirkung
since	Ein Startdatum. Alles, was davor schon fällig gewesen wäre, bleibt unberührt — so wird beim Einschalten nicht der gesamte Altbestand auf einen Schlag umgestellt.
scope	Auf welche Ausgangsstatus die Regel wirkt. Ohne Angabe nur auf den eigenen.
field	Welches Datumsfeld bei inactivity maßgeblich ist.
notify	Unterdrückt die Benachrichtigungen des Zielstatus.
limit	Höchstzahl der Projekte je Durchlauf.

since ist die wichtigste dieser Angaben. Ohne sie erfasst eine neu eingeschaltete Regel beim ersten Lauf sämtliche Altprojekte, die die Bedingung erfüllen — bei einem gewachsenen Bestand können das sehr viele auf einmal sein.

Gut zu wissen

Ein Statuswechsel setzt immer auch den Projekttyp neu, der am Zielstatus hinterlegt ist.

Ob beim Wechsel zusätzlich Mails verschickt und Einträge in der Projekt-Historie geschrieben werden, hängt von der Einrichtung der jeweiligen Instanz ab. Beides ist getrennt schaltbar — eine Instanz kann die Historie führen, ohne Mails zu versenden.

Die Automatik läuft nur, wenn das zugehörige Programm auf dem Server eingerichtet ist. Ist es das nicht, bleiben gepflegte Regeln wirkungslos, ohne dass es im Backend auffällt.

Der Takt wird je Installation auf dem Server gesetzt und ist im Backend nirgends sichtbar — wie oft die Regeln greifen, lässt sich hier also weder ablesen noch ändern. Bei Zweifeln beim Betrieb der Instanz nachfragen.