Hi,
I’ve been sending invites using the api (Discourse API Docs). When I send it on postman, I am getting the invite email. But when I implement it on laravel I’m not getting the email.
Here is the response when the api from laravel. I noticed that the emailed field is false.
Postman response the emailed field is true.
Any advice? Thanks.
someone else also reported this,
check this topic
yes this was a different error which was already resolved. the issue now is we’re not getting emails but using the api is successful.
i’m not sure if we need to enable anything? coz when i call the api on postman i get the email but on the laravel app we’ve created we’re not getting the emails.
مرحباً @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 / قسم الدعوات، فإنه لا يزال يظهر في البريد الإلكتروني للدعوة أنني (المستخدم الخاص بي) من أرسل الدعوة.
أود أن أجرب باستخدام مفتاح واجهة برمجة تطبيقات إداري لاسم المستخدم الخاص بك.
عبر واجهة برمجة التطبيقات، يجب أن تكون قادرًا على الحصول على نفس السلوك كما هو الحال عبر واجهة المستخدم.