Reglas
Qué le pasa al correo cuando llega.
Herramientas de reglas
| Herramienta | Qué hace |
|---|---|
| listRules | Todas las reglas de la conexión activa, en el orden en que se evalúan, con lo que hace cada una y cuántas veces se ha disparado. |
| getRule | Una regla completa: sus condiciones, sus acciones y si está activada. |
| createRule | Escribe una regla: condiciones sobre un mensaje entrante y qué debe ocurrir con todo lo que coincida. La regla se crea DESACTIVADA. |
| testRule | Qué mensajes de los últimos treinta días habría capturado una regla y qué habría hecho con ellos. No cambia nada. |
| setRuleEnabled | Activa o desactiva una regla, una vez que una persona la ha revisado. |
createRule escribe la regla DESACTIVADA, que es el único punto en el que este servidor difiere deliberadamente de la API REST. POST /rules la crea activada por defecto. Una regla que archiva, tira a la papelera o reenvía correo no debería empezar a hacerlo por la fuerza de un mensaje de chat: escríbela, llama a testRule para mostrarle a la persona para la que trabajas cuáles de sus propios mensajes habría capturado, y solo entonces pide setRuleEnabled.
No hay updateRule, ni deleteRule, ni reordenación, por la misma razón por la que no hay eliminación de plantillas: esas son las operaciones que rompen la configuración de otra persona desde dentro de una ventana de chat. Una regla eliminada no se puede restaurar, y una reordenación cambia en silencio lo que ocurre con todos los mensajes futuros. Las tres están en Ajustes → Reglas y en la API REST, donde es una persona la que hace clic.
Las reglas pertenecen a la CONEXIÓN, así que estas actúan sobre el buzón que setActiveConnection haya nombrado por última vez, y una regla que escribió un compañero es una de ellas. Un buzón admite 100 reglas, cada una con como mucho 20 condiciones y 10 acciones.
Nada de esto es retroactivo. Una regla decide qué ocurre con el correo que llega después de activarla; no barre un buzón que ya existe, y testRule informa en lugar de archivar.