سرد تشغيلات القواعد
ما فعلته قواعدك فعلًا، صف واحد لكل قاعدة لكل رسالة.
ينفّذ الاستدعاء الحقيقي على مساحة عملك، بمفتاحك أنت.
GET /rules/runs
ما فعلته قواعدك فعلًا، صف واحد لكل قاعدة لكل رسالة.
مثال
يتطلب rules:read. الأحدث أولًا. وruleId يضيّق إلى قاعدة واحدة، وthreadId يجيب عن «لماذا انتهت هذه الرسالة هنا».
curl "$OE/rules/runs?threadId=thr_5d31c2a8…&limit=25" -H "$AUTH"{ "object": "list", "data": [ { "object": "rule_run", "id": "rrun_9c1f0a4b7e05d3862c1f0a44", "ruleId": "rul_7f3a1c94e05d3862c1f0a44b", "ruleName": "Receipts to their own label", "threadId": "thr_5d31c2a8…", "messageId": "msg_c5f21cc6…", "sender": "[email protected]", "subject": "Your receipt", "actions": ["label", "archive"], "failures": [], "createdAt": "2026-08-29T11:04:12.000Z" } ], "hasMore": false, "nextCursor": null}actions يحمل ما طُبِّق وfailures يحمل ما رُفض، بصيغة type: reason. وهما قائمتان منفصلتان لا قائمة واحدة مشروحة، لأن «القاعدة أرشفتها» و«القاعدة حاولت أرشفتها» حقيقتان مختلفتان، والسجل الذي يخلطهما لا يستطيع الإجابة عن أيٍّ من السؤالين. وهذه أنواع إجراءات مجردة. أما القيم فتقيم على القاعدة، وwouldApply في اختبار هو المكان الوحيد الذي تُذكر فيه صراحةً.
الرد التلقائي المكبوت يظهر هنا، بصيغة reply: auto-reply suppressed because the message carries List-Id، وهذا هو المكان الوحيد الذي يظهر فيه. لا شيء آخر يُظهر ردًّا امتنع عن الخروج عمدًا، و«لماذا لم يُجب ردّي على الغياب عن تلك الرسالة» بلا إجابة لولا ذلك.
ruleName مخزَّن على الصف لا مضموم وقت القراءة، فالسجل يظل يُقرأ بصحة بعد إعادة تسمية قاعدة أو حذفها. والصف الذي يسمّي قاعدة لم تعد موجودة هو الحالة الطبيعية لا مرجعًا معلّقًا.
حدّ الرد التلقائي الواحد لكل مرسِل في اليوم يُفرَض بصف مطالبة في الجدول نفسه، وهو ما لا يُعيده هذا السجل: وهو سبب ألّا يُطلَق ردّ غياب ثانٍ إلى المرسِل نفسه خلال يوم.