Szabályok átrendezése
A teljes sorrend egy hívásban, mert egy szabálylistának csak sorrendben van értelme.
A valódi hívást futtatja le a munkaterületén, a saját kulcsával.
POST /rules/reorder
A teljes sorrend egy hívásban, mert egy szabálylistának csak sorrendben van értelme.
Példa
rules:write szükséges. A törzs a kapcsolat MINDEN szabályát megnevezi, abban a sorrendben, ahogyan a kiértékelésüket szeretnéd. A teljes listát adja vissza az új sorrendben.
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}Egy részleges lista incomplete_order, 422, és semmi nem mozdul. Az elfogadása azt jelentené, hogy pozíciókat kellene kitalálni a kihagyott szabályoknak, és az, hogy azok hová kerülnének a megnevezettekhez képest, a mi találgatásunk lenne a postafiókodról, nem a te utasításod.
Felépítésénél fogva idempotens: a törzs a teljes sorrendet megnevezi, így kétszer elküldve ugyanoda jut. Biztonságosan újrapróbálható, és biztonságosan futtatható egy olyan szkriptből is, amely nem ismeri a jelenlegi sorrendet.
Minden pozíció egyetlen utasításban, egyetlen tranzakción belül íródik újra, így nincs olyan pillanat, amikor két szabály ugyanazon a pozíción állna, vagy a lista félig lenne újraszámozva.
A sorrend nem kozmetikai. Eldönti, hogy két szabály közül melyik nevezi meg azt a mappát, ahová egy üzenet kerül, és hol vágja el a listát egy stopProcessing szabály.