منح شارة مخصصة عبر واجهة برمجة التطبيقات

يمكن منح الشارات المخصصة التي أنشأتها في منتداك عبر واجهة برمجة التطبيقات (API). تُعد هذه طريقة ممتازة لمنح الشارات دون الحاجة إلى استخدام أوامر SQL مخصصة للشارات.

لمنح شارة عبر واجهة برمجة التطبيقات، تحتاج إلى معرفة اسم المستخدم للمستخدم الذي ترغب في منح الشارة له، ومعرف الشارة (أو اسمها) التي ترغب في منحها. كما يجب التأكد من أنك قمت بتوليد مفتاح API من قسم الإدارة > واجهة برمجة التطبيقات > المفاتيح في موقعك (/admin/api/keys).

العثور على معرف الشارة

يمكنك الحصول على معرف الشارة من رابط الشارة. انتقل إلى قسم الإدارة/الشارات في موقعك، ثم انقر على الشارة التي ترغب في منحها. سيبدو الرابط شبيهاً بهذا: https://forum.example.com/admin/badges/102. الرقم الأخير في الرابط هو معرف الشارة.

إجراء مكالمة واجهة برمجة التطبيقات

لاختبار مكالمة واجهة برمجة التطبيقات، يمكنك تجربة منح شارة باستخدام أداة curl أو Postman. إليك كيفية منح شارة من طرفي في سطر الأوامر باستخدام curl.

أولاً، لتسهيل الأمر، قم بتعيين متغير api_key:

 api_key=yourapikey

ثم لمنح شارة بمعرف 102 للمستخدم bobby:

curl -X POST "https://forum.example.com/user_badges" \
-H "Api-Key: $api_key" \
-H "Api-Username: system" \
-F "username=bobby" \
-F "badge_id=102" \
-F "reason=https://forum.example.com/t/whats-the-best-photo-youve-ever-taken/160/2"

بدلاً من badge_id، يمكنك أيضاً استخدام badge_name لتحديد الشارة باسمها:

-F "badge_name=My Custom Badge"

المعلمة reason اختيارية. إذا قمت بتزويدها، فيجب تعيينها إلى رابط موضوع أو منشور في موقعك.

يجب أن تتلقى استجابة بصيغة JSON تحتوي على تفاصيل حول الشارة وتاريخ منحها.

27 إعجابًا

Has anybody added a badge (or flair) via Zapier to Discourse API like outlined here?

Also, seems like a great candidate for an action via the official integration, @HAWK.

3 إعجابات

انظر أيضًا https://meta.discourse.org/t/how-to-create-a-custom-badge-with-an-image-through-the-api/210616، والذي يوضح كيفية التحميل، ويتضمن أيضًا مثالًا آخر لمنح الشارة (بلغة بايثون).

إعجاب واحد (1)

ما هو سبب عدم وصف هذه الطريقة في وثائق واجهة برمجة التطبيقات على https://docs.discourse.org/؟

لم أتمكن من العثور عليها هناك.

إعجابَين (2)

لأنه لا يبدو أن هناك وظيفة لأي شخص للحفاظ على هذه الوثائق كاملة أو محدثة، وقد نشر شخص طيب هذه التعليمات هنا. بشكل عام، وثائق واجهة برمجة التطبيقات هي الهندسة العكسية لواجهة برمجة تطبيقات Discourse والنظر في المصدر.

7 إعجابات

جميل، إذن لا توجد طريقة لأتمتة منح شارات كهذه عبر واجهة برمجة التطبيقات؟

على سبيل المثال، يُمنح شخص ما شارةً لحصوله على 5000 إعجاب على ردوده.

إعجاب واحد (1)

إذا كنت تستضيف بنفسك، أو على إصدار Enterprise، فأنت تريد تمكين شارة SQL.

إعجابَين (2)

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

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

في النهاية، يبدو هذا من نوع الأشياء التي يمكن التعامل معها بواسطة المكون الإضافي للأتمتة. يمكن أن يكون هناك مشغل متكرر يقوم بتشغيل استعلام مستكشف البيانات بمعرف استعلام معين. بناءً على الحقول التي تم إرجاعها بواسطة الاستعلام، يمكن استخدام النتائج لتشغيل نصوص برمجية مختلفة. على سبيل المثال، إذا تم إرجاع حقل username بواسطة الاستعلام، فيمكن استخدامه لتشغيل نصوص برمجية تمنح شارات، أو تضيف مستخدمين إلى مجموعات، وما إلى ذلك.

إعجابَين (2)

ألن يكون هذا له نفس المشاكل التي أدت إلى تعطيل استعلام الشارة في المقام الأول؟

إعجاب واحد (1)

لا أعتقد ذلك. يتم تشغيل استعلامات مستكشف البيانات في كتلة معاملة تنتهي مهلتها بعد 10 ثوانٍ. أعتقد أن الهدف من ذلك هو تجنب نوع المشكلة التي يمكن أن تؤدي إليها استعلامات الشارات. إذا لم يتم تكوين الأشياء بهذه الطريقة، يمكن لاستعلام مستكشف بيانات غير فعال أن يتسبب في تعطل الموقع.

بالتفكير في ذلك الآن، أتساءل عما إذا كان يمكن أن يكون لـ SQL المخصص للشارات نفس النوع من الضمانات.

4 إعجابات