هل يمكن تضمين أسماء المستخدمين في حمولة webhook الخاصة بالشارات؟

هل يمكن أن تتضمن خطافات user_badge حقل username إلى جانب user_id؟ حاليًا، يبدو حمولة حدث user_badge على النحو التالي:

{
  "user_badge": {
    "id": 123456,
    "granted_at": "2026-09-25T14:54:42.073Z",
    "created_at": "2026-09-26T05:34:12.965Z",
    "post_id": 234567,
    "post_number": 1,
    "badge_id": 123,
    "user_id": 456,
    "granted_by_id": -1,
    "topic_id": 56789
  }
}

الحصول على اسم المستخدم المقابل لـ user_id (وأيضًا granted_by_id إذا لم يكن -1) يتطلب إجراء استدعاء إضافي إلى /admin/users/{user_id}.json، وهو ما لا يتطلب فقط طلبات إضافية، بل يتطلب أيضًا صلاحيات المدير على ما أعتقد.

هل هناك طريقة للحصول على username لمستخدم معين بناءً على user_id باستخدام مفتاح API دون الحاجة إلى صلاحيات المدير؟

أقوم بإنشاء خدمة خارجية كنت أأمل في تشغيلها عند منح شارة معينة أو أكثر؛ ومع ذلك، تحتاج الخدمة إلى اسم المستخدم، بينما تُرجع خطافات الشارات معرفات المستخدمين فقط فقط. :confused:

على أي حال، الحل البديل الذي أستخدمه للخطافات (Webhooks) غير القياسية أو عندما أحتاج إلى بيانات إضافية هو تنفيذ ذلك عبر Workflows ثم إرسال ذلك إلى n8n.

للتوضيح، فإن جلب اسم المستخدم من معرّف المستخدم يتطلب فقط استدعاءً واحدًا لواجهة برمجة التطبيقات (API)، ما لم تكن تمنح آلاف الشارات يدويًا في لحظة واحدة، فستكون ضمن حدود API الافتراضية دون أي مشكلة.

شكراً! سأبحث في موضوع Workflows.

هذا خبر رائع! هل يمكنك من فضلك تقديم تفاصيل عن ذلك الاستدعاء الواحد لواجهة برمجة التطبيقات الذي ليس /admin/users/{user_id}.json (والذي يتطلب صلاحيات المسؤول)؟ لم أتمكن من العثور على نقطة نهاية (endpoint) للقيام بذلك بمفتاح واجهة برمجة التطبيقات دون الحاجة إلى صلاحيات المسؤول.

ما المشكلة في مفتاح API الخاص بالمسؤول؟ هذا المفروض أن يكون مهمة في الخلفية، أليس كذلك؟

مبدأ الحد الأدنى من الامتيازات. هذه الخدمة الخارجية ستعمل على خادم آخر وتحتاج فقط إلى صلاحيات القراءة في Discourse لأداء عملها. كلما قل عدد المفاتيح الرئيسية المتداولة عبر البنية التحتية، كان ذلك أفضل.