كيفية استرداد external_id للموضوع برمجياً

[SeanOSullivan]

مرحباً بالجميع،

أحتاج إلى استرداد remote_id لموضوع ما، بشكل برمجي. الخلفية - أقوم بتشغيل نص برمجي على api.onPageChange يسترد معلومات حول الموضوع/الفئة/المجموعة الحالية، ثم يقوم باستدعاء Ajax لنظام خارجي للحصول على معلومات إضافية خاصة بالكيان.

لدي حدث api.onPageChange (ربما ember؟) قيد التشغيل، ويبدو أنني أستطيع الحصول على كل المعلومات التي أحتاجها باستثناء قيمة remote_id (أنا أستخدم اسم الحقل من واجهة برمجة التطبيقات).

ما لدي حتى الآن:

const topicController = api.container.lookup(“controller:topic”);
if (topicController) {
const thisTopic = topicController.get(“model”);
if (thisTopic) {
console.log(thisTopic.category.id); // على سبيل المثال فقط .. يعمل بشكل مثالي.

.. يمكنني الحصول على حقول مختلفة، وكلها تعمل بشكل رائع .. لا أستطيع العثور على كيفية الحصول على Remote ID، على الرغم من ذلك (وأنا بحاجة إليه). أعرف أنني أستطيع الحصول عليه باستخدام استدعاء JSON (بإضافة .json إلى عنوان URL للصفحة الحالية) ولكن هذا يبدو غير فعال .. أم أنني مخطئ، هل يجب أن أستخدم هذا النهج؟ أي توجيهات أخرى؟

شكراً مقدماً!

[simon]

@SeanOSullivan

أعتقد أنني أستطيع الحصول على كل المعلومات التي أحتاجها باستثناء قيمة remote_id

للتأكيد، هل remote_id هو الاسم الفعلي للحقل الذي تبحث عنه؟ لست على علم باستخدام Discourse لهذا الحقل.

[SeanOSullivan]

آه.. اعتذار @simon (وشكراً على التحقق من السؤال).. “external_id” هو الاسم الصحيح، وفقًا لواجهة برمجة التطبيقات.

أعتقد أنني كنت بالفعل أتحقق من الاسم الصحيح (external_id)، لكنني تذكرته بشكل خاطئ عند كتابة السؤال هنا.. لكنني بالتأكيد بحاجة إلى التحقق. لا يمكنني القيام بذلك الآن ولكنني سأعود هنا لاحقًا اليوم.

شكراً مرة أخرى، أقدر ذلك!

[SeanOSullivan]

إذًا .. كنت أبحث عن الحقل/القيمة الخطأ عن طريق الخطأ، وليس الحقل الصحيح (external_id). آسف على إضاعة الوقت .. إذا كان ذلك يعزيني، فقد أضعت الكثير من وقتي الخاص أولاً

الخبر السيئ هو - لا يمكنني العثور على external_id في أي مكان في نموذج Ember. أنا لست على دراية بـ Ember لذا أنا فقط أبحث، حقًا .. يمكنني العثور على الكثير من معلومات Topic المفيدة الأخرى، فقط، ليس external_id (لقد سجلت نموذج Topic في وحدة التحكم وكنت أبحث).

أي اقتراحات، @simon أو أي شخص؟ شكراً مرة أخرى.

[simon]

external_id هو خاصية في نموذج SingleSignOnRecord. يُستخدم لربط مستخدم بموقع خارجي عند استخدام DiscourseConnect لتسجيل دخول المستخدمين إلى Discourse عبر موقع خارجي. إذا كان هذا ما تحاول العثور عليه، فهو غير متاح في الموضوع (Topic). على حد علمي، يعيد Discourse فقط external_id في الواجهة الأمامية لـ CurrentUser، لذلك إذا كنت تحاول القيام بشيء مثل الحصول على external_id لمؤلف الموضوع، فقد يكون الأمر صعبًا.

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

@SeanOSullivan

آسف لإضاعة الوقت

لا مشكلة. هذا ما نحن هنا من أجله

[SeanOSullivan]

شكراً جزيلاً، جميع الأجزاء!

لذا، أتوقع تشغيل مثيلات متعددة من Discourse، بالإضافة إلى نظام إشراف/تنسيق شامل (غير Discourse) في الخلفية. سيتم إضافة المواضيع إلى Discourse بإحدى طريقتين - إما بواسطة المستخدمين عبر آلية إنشاء المواضيع المعتادة في Discourse، أو بواسطة نظام الإشراف/التنسيق عبر واجهة برمجة التطبيقات (API).

عند إنشاء الموضوع عبر واجهة برمجة التطبيقات (API)، فإنه يمثل عادةً مهمة أو عنصر سير عمل مشابه سيكون له بالفعل معرف غير Discourse الخاص به.. لنسميه “المعرف الخارجي”.

عند إنشاء الموضوع بواسطة المستخدم داخل Discourse، سنستخدم خطافات الويب (webhooks) لتشغيل دالة Azure لإنشاء نسخة مبدئية في النظام المركزي (بحيث يتم ربط رسائل Discourse بتيار أوسع من المحتوى والمهام وما إلى ذلك). لذلك، مرة أخرى، سيكون للموضوع في Discourse بشكل غير مباشر “معرف خارجي” فريد - نقترح تحديث الموضوع به، عبر واجهة برمجة التطبيقات (API).

لدينا مكون سمة Discourse مخصص، والذي عند تحميل كل موضوع، سيستخدم Ajax لاسترداد معلومات غير مركزية لـ Discourse من النظام المركزي وعرضها على شاشة الموضوع.

بينما يمكننا استخدام معرف موضوع Discourse لمعلمة استدعاء Ajax والعثور على البيانات المطابقة، إلا أنه أكثر كفاءة استخدام “المعرف الخارجي” للقيام بذلك (إنه ببساطة أنظف، لأسباب متعددة - يتجنب عمليات البحث وما إلى ذلك).

يمكننا بسهولة تخزين “المعرف الخارجي” في حقل مخصص - لدينا بالفعل واحد لبيانات أخرى - لكننا لاحظنا أن واجهة برمجة تطبيقات المواضيع (Topics API) تحتوي على حقل “external_id” يبدو تمامًا كما نحتاج، وأفضل استخدامها لأسباب مختلفة .. إنها تجعل هذا الحقل المحوري إلى حد ما أسهل في دمجه في التقارير والتصديرات، وربما عمليات البحث المستقبلية وما إلى ذلك.

انظر لقطة الشاشة من Discourse API Docs

أعتقد أن هذا حقل جديد إلى حد ما - معظم النصائح في المنتدى تبدو متعلقة بحقل المعرف الخارجي للمستخدم (User external_id)، وهو ليس ما أحتاجه الآن. كما ذكرنا أعلاه، أقوم باسترداد نموذج Ember للموضوع (ضمن مكون السمة المخصص الخاص بي) ويمكنني الحصول على كل المعلومات تقريبًا حول الموضوع من خلاله … ولكن ليس حقل external_id.

(كما هو مذكور أعلاه - أنا أحصل على الموضوع باستخدام هذا الكود، الذي تم اقتراضه من مكان ما في هذا الموقع، لا أعرف أين في هذه المرحلة:

            const topicController = api.container.lookup("controller:topic");
            if (topicController) {
                const thisTopic = topicController.get("model");      

لذا، الطلب - هل حقل المعرف الخارجي الخاص بالموضوع مدفون في النموذج (“thisTopic”) في مكان ما، أم أنني أساء فهم هذه المفاهيم ويجب عليّ فقط استخدام الحقل المخصص لتخزين هذا المعرف الخارجي (أعرف أنني أستطيع جعل هذا النهج يعمل، وكيف! .. أنا فقط أفضل النظافة والاستعداد للمستقبل لاستخدام المعرف الخارجي المميز، إذا كان متاحًا بالفعل).

مرة أخرى، شكراً على المساعدة، أقدر ذلك!

[simon]

@SeanOSullivan

لكننا لاحظنا أن واجهة برمجة تطبيقات المواضيع (Topics API) تحتوي على حقل “external_id” يبدو تمامًا كما نحتاج إليه،

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

<script type="text/discourse-plugin" version="0.11.0">
api.onPageChange (() => {
    const c = api.container.lookup("controller:topic");
    if (c) {
        const m = c.get("model");
        if (m && m.hasOwnProperty('external_id')) {
        console.log("the external_id is ", m.external_id);
        }
    }
});
</script>

[SeanOSullivan]

.. وها هي تتحول من “مستحيل” إلى “رائع” .. رائع، هذا يغير قواعد اللعبة بالنسبة لي. لم يخطر ببالي أن النموذج سيكون متغيراً، ولكنه منطقي تماماً.

شكراً جزيلاً، @simon، بما في ذلك المقتطف الأنيق للكود!