مرحبًا،
لقد كنتُ أُرسل الدعوات باستخدام واجهة برمجة التطبيقات (Discourse API Docs). عندما أُرسلها عبر Postman، أحصل على البريد الإلكتروني للدعوة. لكن عند تطبيقها في Laravel، لا أحصل على البريد الإلكتروني.
إليك الرد عند استخدام الواجهة من Laravel. لاحظت أن حقل emailed يحمل قيمة false.
في رد Postman، يحمل حقل emailed قيمة true.
أي نصيحة؟ شكرًا.
شخص آخر أبلغ عن هذه المشكلة أيضًا،
راجع هذا الموضوع:
نعم، كانت هذه خطأً مختلفًا تم حله بالفعل. المشكلة الآن هي أننا لا نستقبل رسائل البريد الإلكتروني، لكن استخدام واجهة برمجة التطبيقات (API) ناجح.
لست متأكدًا مما إذا كنا بحاجة إلى تمكين أي شيء؟ لأنه عندما أستخدم الـ API عبر Postman، أحصل على البريد الإلكتروني، لكننا في تطبيق Laravel الذي أنشأناه لا نستقبل رسائل البريد الإلكتروني.
مرحباً @yburhaniel،
إنه موضوع قديم بالفعل، ولكني أواجه مشكلة مماثلة. طلب API إلى invite.json ينشئ روابط دعوة، ولكنه لا يرسل البريد الإلكتروني. بينما إذا قام نفس المستخدم الذي يرتبط به مفتاح API بدعوة المستخدمين من واجهة المستخدم، يتم إرسال البريد الإلكتروني بشكل طبيعي.
كيف قمت بحل هذه المشكلة في ذلك الوقت؟
هل قمت بتعيين send_email؟
أنا أستخدم كود بايثون مثل هذا:
invitation = {
"email": u.mail,
"group_ids": valid_group_ids(u.groups),
"send_email": True,
}
site.invites.post(data=invitation)
هل يمكنك أن ترينا الكود الذي تستخدمه؟
مرحباً @thoka،
شكراً على ردك. هل الأمر بهذه البساطة حقاً، ستكون هذه أخبار رائعة!
بالنسبة لهذا الأمر، أنا أستخدم Zapier، ولكن مع كائن أنشأته باتباع وثائق API هذه. ربما هذه ليست الوثيقة الصحيحة أو أنني أفتقد شيئاً آخر.
لقد جربت العديد من المعلمات المختلفة هناك، ولكن آخرها كان:
{
"email": "email@email.com",
"skip_email": false,
"custom_message": "Welcome to the forum",
}
لقد جربت للتو مع ما يلي أيضاً. للأسف لم يتسبب ذلك في إرسال الدعوة:
{
"email": "email@email.com",
"skip_email": false,
"send_email": true,
"custom_message": "Welcome to the forum",
}
ولكن ربما الخصائص التي لدي هناك لا تزال خاطئة بطريقة ما.
أنا دائماً أفعل Reverse engineer the Discourse API لاستخدام نفس المعلمات مثل واجهة المستخدم.
أشياء جيدة، شكراً لك على لفت انتباهي إلى ذلك. أعتقد أن هذه غريزة تأتي مع خبرة أطول في ديسكورس. 
على أي حال، الآن بعد أن قلت ذلك، منطقي تمامًا.
سأحاول وسأعود هنا لأخبرك كيف سارت الأمور!
للأسف، لا تزال المشكلة كما هي، الحالة OK 200، ولكن رابط الدعوة فقط هو الذي تم إنشاؤه.
الواجهة البرمجية للتطبيقات (API) من واجهة المستخدم (UI) أضافت فقط خصائص expires_at و max_redemptions_allowed بشكل صريح.
بالمناسبة، هل يمكن أن تكون مشكلة استخدامي للمستخدم system عبر التكامل؟ مع ذلك، أعتقد أنني استخدمت أيضًا مستخدمًا “بشريًا” فعليًا للاختبار به.
إذا قمت بإنشاء دعوات عبر واجهة المستخدم، فهل يعمل كل شيء كما هو متوقع؟
نعم، هذا هو اللغز، عبر واجهة المستخدم يعمل كل شيء دون مشاكل.
على الرغم من ذلك، لاحظت أنه حتى لو أرسلت الدعوة من ملف تعريف المستخدم system / قسم الدعوات، فإنه لا يزال يظهر في البريد الإلكتروني للدعوة أنني (المستخدم الخاص بي) من أرسل الدعوة.
أود أن أجرب باستخدام مفتاح واجهة برمجة تطبيقات إداري لاسم المستخدم الخاص بك.
عبر واجهة برمجة التطبيقات، يجب أن تكون قادرًا على الحصول على نفس السلوك كما هو الحال عبر واجهة المستخدم.