Правила
Что происходит с почтой при поступлении.
Инструменты правил
| Инструмент | Что делает |
|---|---|
| listRules | Все правила активного подключения, в порядке их вычисления, с тем, что каждое делает и как часто срабатывало. |
| getRule | Одно правило целиком: его условия, его действия и включено ли оно. |
| createRule | Написать правило: условия для приходящего письма и что должно произойти со всем, что им соответствует. Правило создаётся ВЫКЛЮЧЕННЫМ. |
| testRule | Какие из писем за последние тридцать дней правило поймало бы и что бы оно с ними сделало. Ничего не меняет. |
| setRuleEnabled | Включить или выключить одно правило — после того, как человек его прочитал. |
createRule записывает правило ВЫКЛЮЧЕННЫМ, и это единственное место, где этот сервер намеренно отличается от REST API. POST /rules по умолчанию создаёт включённое. Правило, которое архивирует, отправляет в корзину или пересылает почту, не должно начинать это делать на основании сообщения в чате: напишите его, вызовите testRule, чтобы показать человеку, на которого вы работаете, какие из его собственных писем оно поймало бы, и только после этого просите setRuleEnabled.
Нет ни updateRule, ни deleteRule, ни изменения порядка — по той же причине, по которой нет удаления шаблонов: это те операции, которые ломают чужую настройку из окна чата. Удалённое правило нельзя восстановить, а изменение порядка незаметно меняет судьбу каждого будущего письма. Все три есть в разделе Настройки → Правила и в REST API, где кликает человек.
Правила принадлежат ПОДКЛЮЧЕНИЮ, поэтому они действуют на тот ящик, который последним назвал setActiveConnection, и правило, написанное коллегой, — одно из них. Ящик держит 100 правил, у каждого не более 20 условий и 10 действий.
Ничто здесь не работает задним числом. Правило решает, что происходит с почтой, приходящей после его включения; оно не подметает уже существующий ящик, а testRule отчитывается, а не раскладывает.