Regeln neu anordnen
Die gesamte Reihenfolge in einem Aufruf, weil eine Regelliste nur in ihrer Reihenfolge etwas bedeutet.
Führt den echten Aufruf gegen Ihren Workspace aus, mit Ihrem eigenen Schlüssel.
POST /rules/reorder
Die gesamte Reihenfolge in einem Aufruf, weil eine Regelliste nur in ihrer Reihenfolge etwas bedeutet.
Beispiel
Benötigt rules:write. Der Body nennt JEDE Regel auf der Connection, in der Reihenfolge, in der sie ausgewertet werden sollen. Liefert die vollständige Liste in ihrer neuen Reihenfolge.
curl -X POST "$OE/rules/reorder" -H "$AUTH" -H "Content-Type: application/json" \ -d '{ "ruleIds": ["rul_7f3a1c94…", "rul_2b81de07…", "rul_c40a95f2…"] }'{ "object": "list", "data": [ { "object": "rule", "id": "rul_7f3a1c94…", "name": "Receipts to their own label", "position": 0 }, { "object": "rule", "id": "rul_2b81de07…", "name": "Newsletters after hours", "position": 1 }, { "object": "rule", "id": "rul_c40a95f2…", "name": "Anything from the old domain", "position": 2 } ], "hasMore": false, "nextCursor": null}Eine unvollständige Liste ist incomplete_order, ein 422, und nichts bewegt sich. Sie anzunehmen hieße, Positionen für die ausgelassenen Regeln zu erfinden, und wo diese relativ zu den genannten landen, wäre unsere Vermutung über Ihr Postfach und nicht Ihre Anweisung.
Konstruktionsbedingt idempotent: Der Body nennt die gesamte Reihenfolge, zweimal gesendet landet er also am selben Punkt. Ein erneuter Versuch ist gefahrlos, ebenso der Aufruf aus einem Skript, das die aktuelle Reihenfolge nicht kennt.
Jede Position wird in einer einzigen Anweisung innerhalb einer Transaktion neu geschrieben; es gibt also keinen Moment, in dem zwei Regeln dieselbe Position teilen oder die Liste halb neu nummeriert ist.
Die Reihenfolge ist nicht kosmetisch. Sie entscheidet, welche von zwei Regeln den Ordner nennt, in dem eine Nachricht landet, und an welcher Stelle eine stopProcessing-Regel die Liste abschneidet.