قواعد
آنچه هنگام رسیدن ایمیل بر سرش میآید.
ابزارهای قواعد
| ابزار | چه میکند |
|---|---|
| listRules | هر قاعده روی اتصال فعال، به ترتیبی که ارزیابی میشوند، با کاری که هرکدام میکند و اینکه چند بار شلیک کرده است. |
| getRule | یک قاعده بهطور کامل: شرطهایش، کنشهایش و اینکه روشن است یا نه. |
| createRule | یک قاعده بنویسید: شرطهایی روی پیامی که میرسد، و اینکه بر سر هر چیزی که با آنها بخواند چه بیاید. قاعده بهصورت غیرفعال ساخته میشود. |
| testRule | اینکه یک قاعده کدامیک از پیامهای سی روز گذشته را میگرفت و با آنها چه میکرد. چیزی را تغییر نمیدهد. |
| setRuleEnabled | یک قاعده را روشن یا خاموش کنید، پس از آنکه کسی آن را خوانده باشد. |
createRule قاعده را غیرفعال مینویسد، و این تنها جایی است که این سرور عمداً با REST API فرق دارد. POST /rules پیشفرض فعال است. قاعدهای که ایمیل را بایگانی، زباله یا هدایت میکند نباید بهاتکای یک پیام در گفتوگو شروع به این کار کند: بنویسیدش، testRule را صدا بزنید تا به کسی که برایش کار میکنید نشان دهید کدامیک از پیامهای خودش را میگرفت، و تنها آنگاه setRuleEnabled را بخواهید.
نه updateRule هست، نه deleteRule و نه تغییر ترتیب، به همان دلیلی که حذف قالب نیست: اینها همان عملیاتیاند که از درون پنجرهٔ گفتوگو تنظیمات کس دیگری را خراب میکنند. قاعدهٔ حذفشده بازگردانی ندارد، و تغییر ترتیب خاموشانه عوض میکند که هر پیام آینده چه سرنوشتی پیدا میکند. هر سه در Settings → Rules و روی REST API هستند، جایی که کلیککننده یک آدم است.
قاعدهها به اتصال تعلق دارند، پس اینها روی همان صندوقی عمل میکنند که setActiveConnection آخرین بار نام برده، و قاعدهای که همکارتان نوشته یکی از آنهاست. هر صندوق 100 قاعده نگه میدارد، هرکدام با حداکثر 20 شرط و 10 کنش.
هیچ چیزی اینجا گذشتهنگر نیست. قاعده تعیین میکند بر سر ایمیلی که پس از فعال شدنش میرسد چه بیاید؛ صندوقی را که از پیش وجود دارد جارو نمیکند، و testRule گزارش میدهد، نه اینکه چیزی را بایگانی کند.