Regras
O que acontece ao correio à medida que chega.
Ferramentas de regras
| Ferramenta | O que faz |
|---|---|
| listRules | Todas as regras da ligação ativa, pela ordem em que são avaliadas, com o que cada uma faz e quantas vezes disparou. |
| getRule | Uma regra por inteiro: as condições, as ações e se está ativa. |
| createRule | Escreve uma regra: condições sobre uma mensagem que chega, e o que deve acontecer ao que lhes corresponder. A regra é criada DESATIVADA. |
| testRule | Quais das mensagens dos últimos trinta dias uma regra teria apanhado, e o que lhes teria feito. Não altera nada. |
| setRuleEnabled | Liga ou desliga uma regra, depois de uma pessoa a ter lido. |
O createRule escreve a regra DESATIVADA, que é o único ponto em que este servidor difere deliberadamente da API REST. O POST /rules fica ativo por omissão. Uma regra que arquiva, deita no lixo ou reencaminha correio não deve começar a fazê-lo por força de uma mensagem numa conversa: escreva-a, chame o testRule para mostrar à pessoa para quem trabalha quais das mensagens dela teria apanhado, e só então peça o setRuleEnabled.
Não existe updateRule, nem deleteRule, nem reordenação, pela mesma razão por que não existe eliminação de modelos: são as operações que estragam a configuração de outra pessoa a partir de uma janela de conversa. Uma regra apagada não pode ser restaurada, e uma reordenação altera em silêncio o que acontece a todas as mensagens futuras. As três estão em Definições → Regras e na API REST, onde é uma pessoa a carregar nos botões.
As regras pertencem à LIGAÇÃO, pelo que estas agem sobre a caixa de correio que o setActiveConnection indicou por último, e uma regra escrita por um colega é uma delas. Uma caixa de correio comporta 100 regras, cada uma com no máximo 20 condições e 10 ações.
Nada aqui é retroativo. Uma regra decide o que acontece ao correio que chega depois de estar ativa; não varre uma caixa de correio já existente, e o testRule relata em vez de arrumar.