هل هذا مرتبط بحقيقة أن API https://{defaultHost}/invites/link.json توقف عن العمل اليوم؟
إعجاب واحد (1)
لست متأكدًا - قد يكون كذلك؟ أنا غير ملم بهذا نقطة النهاية.
حسناً، تلقينا مئات الرسائل الإلكترونية من نظام الأتمتة الخاص بنا تفيد بفشلها. كنا نستخدم نقطة النهاية https://{defaultHost}/invites/link وبدأنا نتلقى أخطاء 404. راجعت الوثائق، وأُبلغ الآن أن نقطة النهاية هي https://{defaultHost}/invites/link.json (مع إضافة .json)، ولكن حتى مع هذا التغيير، لا أزال أحصل على أخطاء 404.
لست متأكداً من كيفية حل هذه المشكلة. نحن بحاجة إلى إنشاء روابط دعوة لإرسالها عبر أنظمتنا. كان كل شيء يعمل بشكل ممتاز حتى اليوم.
أيضًا، عند إرسال طلب PUT إلى هذا العنوان، يُرجع خطأ ‘طلب غير صالح’، بينما يُرجع طلب PUT إلى عنوان غير موجود خطأ ‘غير موجود’. لست متأكدًا مما إذا كان هذا مؤشرًا على أن نقطة النهاية موجودة ولكنها لا تعمل فقط.
ربما يجب أن أوضح أن لدي نسخة من Discourse مستضافة من قبلكم على https://d.strumenta.community/
تم نقل نقطة نهاية واجهة برمجة التطبيقات هذه إلى https://{defaultHost}/invites.json حيث قمنا بدمج دعوات البريد الإلكتروني ودعوات الروابط.
إعجابَين (2)
حسناً، أعتقد أن الوثائق ليست محدثة
هل ينشئ هذا النقطة رابط دعوة، لكنه لا يرسل بريدًا إلكترونيًا؟
لأنه وفقًا للوثائق، فإن الفرق بين /invites.json و /invites/link.json هو إرسال البريد الإلكتروني
إعجاب واحد (1)
أيضًا، عند إرسال طلب إلى /invites.json، أحصل على خطأ BAD REQUEST —> خطأ مني، كان علي استخدام " بدلاً من '
بعد التصحيح، أحصل على رد يخبرني بأن المستخدم تم إرسال بريد إلكتروني إليه، وأود منع ذلك:
سيكون من المفيد الحصول على إشعار عند حدوث تغييرات في واجهة برمجة التطبيقات (API) والحصول على الوصول إلى التوثيق الحالي، وإلا فإن الأمور تنكسر فجأة ولا يمكن إصلاحها…
أضفت هذا هنا فقط للوضوح:
$ curl 'http://localhost:3000/invites.json' -X 'POST' \
-H "Api-Key: d5fc02c5f4efaafacc82e4ff3410ae283d1c5da68ac43430d5133aaf4785593f" \
-H "Api-Username: dan" \
-H "Content-Type: application/json" \
-d "{\"max_redemptions_allowed\":5}"
{"id":18,"link":"http://localhost:3000/invites/6f524dba4ced35ecae709a8614db3b05","redemption_count":0,"max_redemptions_allowed":5,"custom_message":null,"updated_at":"2021-03-10T15:44:44.259Z","expires_at":"2021-04-09T15:44:44.258Z","expired":false,"topics":[],"groups":[]}%
سأقوم بتحديث وثائق واجهة برمجة التطبيقات (API) الخاصة بنا. شكرًا لك على لفت انتباهي إلى ذلك، وآسف على الإزعاج.
7 إعجابات
سيكون من الرائع لو أن create تُرجع رابط الدعوة الموجود مسبقًا بدلاً من إلقاء خطأ إذا كان من نفس المستخدم. استجابة الخطأ 422 عامة جدًا، واستغرق مني وقتًا طويلًا لمعرفة سبب فشل اختباراتي.
إعجاب واحد (1)
تم إضافة طلب سحب لاسترداد دعوة موجودة عبر عنوان البريد الإلكتروني: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
إعجاب واحد (1)
لقد وجدت علمًا غير موثق skip_email يمنع إرسال البريد الإلكتروني، مما يتيح لك فقط الحصول على الرابط. مرره في الجسم مع البريد الإلكتروني وستكون على ما يرام!
{
"email": "someone@test.com",
"skip_email": "true"
}
لقد أجريت بعض الاختبارات السريعة، وتجدر الإشارة إلى أنه إذا استخدمته لتوليد رابط بريد إلكتروني، فلا يمكنك العودة لاستخدامه لإرسال بريد إلكتروني تلقائيًا - emailed يعيد دائمًا قيمة false بمجرد استخدام skip_email.
إعجاب واحد (1)
هل هناك أي سبب لعدم وجود invites/retrieve في التوثيق تحت Discourse API Docs أم أنني أغفل شيئًا ما.
أريد دعوة عناوين بريد إلكتروني موجودة في قاعدة بيانات خارجية، فقط إذا أ) لم يكن لديهم حساب بالفعل، و ب) إذا لم تتم دعوتهم بالفعل (ستعمل هذه العملية بشكل دوري ولا أريد إرسال رسائل غير مرغوب فيها للأشخاص الذين لم يستجيبوا لدعوتهم بسرعة كافية). يبدو أن invites/retrieve.json هي الطريقة الصحيحة لمعرفة (ب) بناءً على ما يبدو في الالتزام (commit).
إعجابَين (2)
من المحتمل أن يكون مجرد سهو لكونه مفقودًا من وثائق واجهة برمجة التطبيقات (API)، وسأعمل على إضافته.
3 إعجابات
سيكون من الرائع لو تم إنشاء هذه الوثائق بواسطة، أو على الأقل اختبارها مقابل، نواة ديسكورس (Discourse core) الحالية.
قد يبدو أنه توجد طريقة بسيطة إلى حد ما (مما يعني على الأرجح يومين من العمل وليس الساعة التي أتمنى أن أصدقها!) لتشغيل المواصفات لاختبارها. أوه، أو ربما هذا ما من المفترض أن يفعله https://redocly.com/؟
ما سيكون لطيفًا حقًا لحالة الاستخدام الخاصة بي هو طريقة لاسترداد جميع الدعوات التي دعاها جميع المستخدمين. إذا كانت عبارة “بواسطة جميع المستخدمين” هي نقطة الانهيار، فسيكون من الجيد لحالة الاستخدام الخاصة بي استرداد جميع الدعوات (بغض النظر عن الحالة).
باستخدام هذه الطريقة، أُجبر على استقصاء كل احتمال، والذي يمكن أن يكون 1000 عنوان بريد إلكتروني عندما يكون هناك على الأرجح عدد قليل فقط في الجدول.
يشير How to get a password from database? - #3 by pfaffman إلى أن قاعدة البيانات غير مكشوفة افتراضيًا، لذا فإن استخدام التعليمات البرمجية للوصول إلى قاعدة البيانات من عملية خارجية ليس ممكنًا بشكل مباشر، على الأقل ليس مع تطبيقي الحالي - وربما لن تكون فكرة جيدة الكشف عن منفذ قاعدة البيانات على أي حال.
أحاول أتمتة الدعوات وعضوية المجموعة لعناوين البريد الإلكتروني في قاعدة بيانات خارجية.
ومرت مرتين بالإشارة إلى إضافة مستكشف البيانات (data explorer plugin)، وهو أيضًا الحل هنا، ولكن ربما تحتاج إلى معرفة أنه يمكنك Run Data Explorer queries with the Discourse API
آه نعم، كانت تلك هي النقطة الأساسية التي كنت أفتقدها - شكرًا على التوجيه
إعجاب واحد (1)