Reguły
Co dzieje się z pocztą, gdy przychodzi.
Narzędzia reguł
| Narzędzie | Co robi |
|---|---|
| listRules | Każda reguła na aktywnym połączeniu, w kolejności, w jakiej są obliczane, z opisem działania każdej z nich i liczbą uruchomień. |
| getRule | Jedna reguła w całości: jej warunki, jej działania i to, czy jest włączona. |
| createRule | Napisz regułę: warunki dotyczące przychodzącej wiadomości i to, co ma się stać z tym, co je spełnia. Reguła powstaje WYŁĄCZONA. |
| testRule | Które wiadomości z ostatnich trzydziestu dni reguła by złapała i co by z nimi zrobiła. Niczego nie zmienia. |
| setRuleEnabled | Włącz lub wyłącz jedną regułę, gdy człowiek już ją przeczytał. |
createRule zapisuje regułę WYŁĄCZONĄ i jest to jedyne miejsce, w którym ten serwer celowo różni się od REST API. POST /rules domyślnie tworzy ją włączoną. Reguła, która archiwizuje, wyrzuca do kosza albo przekazuje pocztę, nie powinna zaczynać tego robić na podstawie wiadomości na czacie: napisz ją, wywołaj testRule, żeby pokazać osobie, dla której pracujesz, które z jej własnych wiadomości reguła by złapała, i dopiero wtedy poproś o setRuleEnabled.
Nie ma updateRule, deleteRule ani zmiany kolejności z tego samego powodu, dla którego nie ma usuwania szablonów: to właśnie te operacje psują cudzą konfigurację z okna czatu. Usuniętej reguły nie da się przywrócić, a zmiana kolejności po cichu zmienia to, co dzieje się z każdą przyszłą wiadomością. Wszystkie trzy są w Settings → Rules i w REST API, gdzie klika człowiek.
Reguły należą do POŁĄCZENIA, więc te narzędzia działają na skrzynce ostatnio wskazanej przez setActiveConnection, a reguła napisana przez kolegę jest jedną z nich. Skrzynka mieści 100 reguł, każda z maksymalnie 20 warunkami i 10 działaniami.
Nic tutaj nie działa wstecz. Reguła decyduje o tym, co dzieje się z pocztą przychodzącą po jej włączeniu; nie przeczesuje istniejącej już skrzynki, a testRule raportuje, zamiast cokolwiek porządkować.