نود دمج Discourse في أنظمتنا الحالية، لإزالة الاعتماد على خادم Discord الخاص بنا للدعم. لدينا بالفعل نظام حساب خاص بنا مُعد، ونود إعادة استخدامه إن أمكن لتقليل الاحتكاك. ومع ذلك، لا يُشترط أن تكون عناوين البريد الإلكتروني فريدة في حالتنا، فقط أسماء المستخدمين. يبدو أن Discourse يعتمد على افتراض أن رسائل البريد الإلكتروني ستكون فريدة عالميًا، مما يمنعنا من التكامل المباشر.
لقد اطلعت على DiscorseConnect والذي بدا واعدًا، ولكنه ينص على:
يستخدم Discourse رسائل البريد الإلكتروني لربط المستخدمين الخارجيين بمستخدمي Discourse
وهو ما لن يعمل في حالتنا، حيث يمكن لعدة حسابات (وتفعل ذلك) استخدام نفس عنوان البريد الإلكتروني.
ومع ذلك، لاحقًا يذكر إدخال عنوان بريد إلكتروني يدويًا إذا لم يتم توفيره من مصدر OAuth:
لاحظ أنني حذفت مسار البريد الإلكتروني: SoundCloud لا يوفر بريدًا إلكترونيًا، لذا سيتعين على المستخدم تقديمه والتحقق منه عند التسجيل لأول مرة في Discourse
هل استخدام Discourse لا يزال شيئًا ممكنًا في حالتنا؟ سيكون تقديم المستخدمين لعنوان بريد إلكتروني يدويًا عند تسجيل الدخول إلى Discourse لأول مرة مناسبًا في حالتنا، ولكن فقط إذا تمكنا من تعطيل القدرة على استخدام عنوان بريد إلكتروني أثناء عملية تسجيل الدخول الفعلية (مما يتطلب استخدام اسم المستخدم وكلمة المرور فقط)، حيث لا يمكننا ربط بريد إلكتروني بشكل موثوق بمستخدم فريد. إن القدرة على تعطيل ذلك من نموذج تسجيل الدخول تمامًا من شأنه أن يقلل الاحتكاك من جانبنا لأنه لن يكون شيئًا ندعمه على أي حال، ونود منع المستخدمين من محاولة القيام بذلك.
لقد أخذنا هذا في الاعتبار ولكن لم نكن متأكدين من كيفية تأثير ذلك على تدفق OAuth أو ما إذا كان سيضيف احتكاكًا للتسجيل/تسجيل الدخول. سيكون هذا النوع من التغيير غير مرئي للمستخدم، لذلك سيفشل في تسجيل الدخول ما لم يدخل عنوان البريد الإلكتروني المعدل هذا. لن يكون خادم الحساب الحالي لدينا على علم بهذه التعديلات، لذلك حتى لو أدخلوا البريد الإلكتروني المعدل، فلن نتمكن من العثور عليه في سجلاتنا؟
وهذا من شأنه أيضًا أن يكسر المستخدمين الذين يستخدمون بالفعل الأسماء المستعارة للبريد الإلكتروني، أليس كذلك؟
إذا سمحت بتسجيل الدخول عبر البريد الإلكتروني (والذي أعتقد أنه لا يمكنك فعله مع DiscourseConnect) فسيتم ذلك ببساطة إذا تم إرسال رابط بريد إلكتروني إليهم.
ستحتاج إلى جعله مدركًا. أعتقد أن هذه ستكون الخطوة الأولى.
خيار آخر غير أنيق سيكون السماح فقط للمستخدم “الأول” (مهما تم تعريفه) بتسجيل الدخول إلى Discourse على الإطلاق.
حل آخر غير أنيق سيكون إجبار المستخدمين على نظامك على الحصول على عناوين فريدة لكل حساب.
حسنًا، نعم. بالطبع سيكون هذا هو الحال، وهذا ما أستهدفه. كنت أبحث عن حل يمنع تسجيل الدخول بالبريد الإلكتروني على الإطلاق، تاركًا تسجيلات الدخول باسم المستخدم كطريقة وحيدة. أنا على ما يرام مع كسر دعم البريد الإلكتروني تمامًا (لا توجد إشعارات بريد إلكتروني على سبيل المثال) عن طريق إعطاء عناوين بريد إلكتروني وهمية تمامًا من خادم OAuth. ولكن هذا يخلق احتكاكًا إذا كانت القدرة على استخدام البريد الإلكتروني لتسجيل الدخول لا تزال متاحة، حيث سيحاول المستخدمون القيام بذلك ويفشلون.
هذا سيجبرنا بشكل أساسي على تتبع بريدين إلكترونيين منفصلين لكل مستخدم، وهو أمر غير مرغوب فيه أيضًا، وكما ذكر @supermathie، فإنه ليس مضمونًا حتى العمل مع جميع الموفرين، ولا يزال يسبب احتكاكًا حيث يتعين علينا الآن إخبار المستخدمين بعنوان البريد الإلكتروني الخاص بهذا المنتدى الذي يتعين عليهم تذكره.
نعم، هذا سيعمل من الناحية الفنية. ولكن لأسباب واضحة لن يكون حلاً حقيقيًا للاستخدام، لأنه سيمنع الآخرين من الانضمام إلى المنتدى على الإطلاق.
هذا ليس شيئًا يمكننا القيام به لأسباب فنية. وأوضحها هو أن لدينا بالفعل مستخدمين لديهم نفس عنوان البريد الإلكتروني مثل الحسابات الأخرى. ولكن الأكبر هو أننا ببساطة لا نستطيع فعل ذلك. المشروع الذي نتطلع إلى دمج Discourse فيه هو Pretendo Network، وهو مشروع محاكاة خادم لشبكة Nintendo. سمحت Nintendo لنظام حساباتها بإعادة استخدام عناوين البريد الإلكتروني، ولذلك لمحاكاة الخوادم بدقة، يتعين علينا القيام بذلك أيضًا. إجبار رسائل البريد الإلكتروني الفريدة ليس في بطاقاتنا.
اقترح أحد أعضاء فريقي أن نقوم بتشغيل خادم SMTP الخاص بنا والذي يتعامل مع تعيين رسائل البريد الإلكتروني الوهمية لـ Discourse إلى رسائل البريد الإلكتروني الفعلية لمستخدمينا، وإعادة توجيه رسائل البريد الإلكتروني المرسلة من Discourse بهذه الطريقة. وهذا سيعمل، ولكنه يأتي بوضوح بتكلفة فنية أعلى لنا ولا يزال لا يحل مشكلة تعطيل تسجيل الدخول عبر البريد الإلكتروني والاحتكاك المذكور سابقًا الذي يأتي مع حالتنا.
يبدو أنه قد يتعين علينا فقط إنشاء نسخة من Discourse أو استخدام حل منتدى آخر للقيام بما نحتاجه.
أتذكر من الذاكرة، ولكن يمكنك استخدام DiscourseConnect مع عناوين بريد إلكتروني وهمية ولكن فريدة. إذا كانت أسماء المستخدمين مضمونة لتكون فريدة من جانبك، يمكن أن يكون التنفيذ بسيطًا جدًا. يمكن تعيين عنوان البريد الإلكتروني لشيء مثل username@invalid.com.
سيقوم المستخدمون بتسجيل الدخول إلى نظامك بالطريقة التي يستخدمونها الآن. سيقوم نظامك بعد ذلك بإنشاء حمولة SSO بعنوان البريد الإلكتروني الوهمي.
العيب في هذا النهج هو أنك ستحتاج إلى تعطيل رسائل البريد الإلكتروني على Discourse. يمكن القيام بذلك عن طريق تعيين الإعداد disable emails إلى yes أو إلى non-staff (إذا كان لدى موظفيك عناوين بريد إلكتروني فريدة).
يمكنك أيضًا التفكير في استخدام عناوين البريد الإلكتروني التي تبدأ بـ “+” للمستخدمين الذين لديهم عناوين بريد إلكتروني مكررة. آخر مرة تحققت فيها، اعتبرت Discourse عناوين البريد الإلكتروني التي تبدأ بـ “+” فريدة. فقط تأكد من تشفير عناوين البريد الإلكتروني قبل استخدامها في حمولة DiscourseConnect. الخطر هنا هو أنه إذا كان لدى المستخدمين عناوين بريد إلكتروني مكررة ويستخدمون خادم بريد لا يدعم عناوين البريد الإلكتروني التي تبدأ بـ “+”، فلن يتلقوا رسائل بريد إلكتروني من Discourse، ولكنه سيسمح لمستخدميك الآخرين بتلقي رسائل بريد إلكتروني من Discourse.
نعم، ولكن فقط لحالة معينة. إذا أنشأ مستخدم حساب Discourse قبل أن يقوم موقع Discourse بتطبيق DiscourseConnect، فسيحاول Discourse ربط المستخدمين الحاليين بعنوان البريد الإلكتروني الموجود في حمولة DiscourseConnect. إذا كنت تبدأ موقع Discourse جديدًا، فلن تكون هذه مشكلة.
حالة أخرى رأيت فيها مشكلة ربط البريد الإلكتروني تحدث هي عندما، بسبب بعض التعليمات البرمجية المعيبة على موقع مزود المصادقة، أصبحت سجلات SSO على موقع Discourse تالفة. في هذه الحالة، تمكن الموقع من حذف جميع سجلات SSO على جانب Discourse، ثم جعل Discourse يربط المستخدمين بعنوان البريد الإلكتروني لحمولة SSO في المرة التالية التي قاموا فيها بتسجيل الدخول. ثم قام Discourse بإنشاء سجلات SSO جديدة للمستخدمين. سيظل هذا يعمل مع عناوين البريد الإلكتروني الوهمية.
المنطق مع مصادقة DiscourseConnect هو أن Discourse يحاول أولاً العثور على المستخدم بناءً على حقل external_id في الحمولة، إذا لم يجد مستخدمًا، فإنه يعود لمحاولة العثور على المستخدم بناءً على حقل email في الحمولة، إذا لم يجد مستخدمًا بعد، فإنه يطرح خطأ.
تحقق من كل هذا جيدًا قبل تنفيذه فعليًا على موقع مباشر، ولكنني أعلم أن نهج البريد الإلكتروني الوهمي قد تم استخدامه على مواقع الإنتاج للحالات التي لا يمكن فيها مشاركة عناوين البريد الإلكتروني الحقيقية للمستخدمين مع موقع Discourse.
@simon شكراً على المعلومات! يبدو أننا أحرزنا تقدماً
هذا جيد، وذكرت سابقًا أن هذا حل مقبول لمشكلة “يجب أن تكون جميع رسائل البريد الإلكتروني فريدة”. أنا على ما يرام تمامًا مع تعطيل رسائل البريد الإلكتروني فعليًا في حالتنا، وكان استخدام رسائل البريد الإلكتروني الوهمية حلاً توصلت إليه قبل نشر هذا المنشور.
ربما لم أكن واضحًا في الأصل، ولكن النقطة من المنشور كانت معرفة ما إذا كان من الممكن إجبار موجه تسجيل الدخول على قبول أسماء المستخدمين فقط، حيث أن تسجيل الدخول حاليًا يمكن أن يتم إما باسم مستخدم أو بريد إلكتروني. إذا كانت تسجيلات الدخول عبر البريد الإلكتروني لا تزال معروضة على أنها متاحة في موجه تسجيل الدخول على Discourse، فقد يحاول المستخدمون لدينا استخدام عنوان البريد الإلكتروني لحسابهم الحالي ويواجهون خطأ. لذلك، إما أن نتعامل مع الأشخاص الذين يحاولون، ويفشلون، في استخدام عنوان بريدهم الإلكتروني الحالي أو بطريقة ما نبلغ المستخدم بعنوان البريد الإلكتروني الجديد الخاص بالمنتدى. يمكن أن يسبب كلاهما ارتباكًا وصعوبة للمستخدمين، لذلك من الناحية المثالية يمكننا ببساطة تقييد موجه تسجيل الدخول لقبول أسماء المستخدمين فقط.
للأسف، لا يضمن أن يكون لدى الموظفين عناوين بريد إلكتروني فريدة أيضًا، لذلك لن أرغب في الاعتماد عليها. هل هذا الإعداد يعطل إرسال البريد الإلكتروني فقط؟ أم أنه يعطل استخدام البريد الإلكتروني ككل، مثل ما أبحث عنه مع موجه تسجيل الدخول؟
لقد نظرت في صفحة DiscourseConnect عدة مرات ولم أر هذا الخيار هناك. هل هناك ربما مكان أفضل لرؤية هذا النوع من التوثيق؟ لم أر أي روابط لأي توثيق كامل في هذا المنشور، لذلك افترضت أن كل المعلومات هناك هي كل ما هو متاح.
أعترف أنني لم أقم بإعداد DiscourseConnect بنفسي للتعمق في الإعدادات. كنت آمل أن يكون التوثيق كافياً لفهم ما يمكن وما لا يمكن القيام به، حتى لا نضطر إلى إعداد نسخة اختبار كاملة للمنتدى إلا إذا كنا نعلم أننا سنلتزم بها. ولكن يبدو أنه لا تزال هناك بعض المعلومات غير متاحة بسهولة، إلا إذا فاتني شيء واضح؟
تم النظر في هذا أيضًا في وقت سابق في هذا الموضوع، ولكن المشكلة لا تزال قائمة وهي أنه سيتعين علينا إما التعامل مع تسجيلات الدخول الفاشلة عبر البريد الإلكتروني أو إخبار المستخدم بعنوان البريد الإلكتروني الجديد للمنتدى. إزالة هذا الاحتكاك كان هدفي الرئيسي. إذا لم يكن هذا ممكنًا هنا دون تعديل Discourse نفسه، وكان الحل الوحيد هو إما التعامل مع تسجيلات الدخول الفاشلة عبر البريد الإلكتروني أو إعطاء الأشخاص بريدًا إلكترونيًا جديدًا لتذكره، فقد نكون أفضل حالًا مع حل منتدى مختلف.
لقد أسأت فهم ذلك على ما يبدو، وهذا ليس واضحًا جدًا بناءً على المنشور نفسه. ومع ذلك، كانت نقطتي عند طرح ذلك هي توضيح الاعتماد على أن تكون رسائل البريد الإلكتروني فريدة، وهو ما سيظل مشكلة.
هذا بالتأكيد لم يكن واضحًا بناءً على المنشور وحده، إلا إذا فاتني شيء ما. شكراً لك على هذا التوضيح! هذا يبدو أقرب إلى ما كنت آمله.
على حد علمي، لا يمكن إجبار موجه تسجيل الدخول في Discourse على عرض حقل اسم المستخدم فقط. ستكون عالقًا أيضًا في محاولة معرفة كيفية تسجيل المستخدمين في المقام الأول. لهذا السبب أقترح DiscourseConnect.
عند تمكين DiscourseConnect، يصبح نظام المصادقة الوحيد لموقع Discourse الخاص بك. عندما ينقر المستخدمون على زر تسجيل الدخول في Discourse، سيتم إعادة توجيههم تلقائيًا إلى عنوان URL الذي أضفته إلى إعداد الموقع discourse_connect_url. يتولى نظام المصادقة الخاص بك الأمر من هناك. هذا يعني أنه إذا كان لديك موقع يمكن للمستخدمين تسجيل الدخول إليه حاليًا باستخدام أسماء المستخدمين وكلمات المرور، فسيستمرون في تسجيل الدخول بهذه الطريقة.
يتطلب إعداد هذا أن تكون قادرًا على إضافة بعض التعليمات البرمجية إلى الواجهة الخلفية للموقع الذي يقوم المستخدمون بتسجيل الدخول إليه الآن. ليس من الصعب إعداده. هناك أمثلة جيدة للتعليمات البرمجية للانطلاق منها هنا: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. يمكنك أيضًا الحصول على بعض المساعدة بشأن ذلك في هذا المنتدى.
إذا لم يكن من الممكن إضافة تعليمات برمجية إلى موقعك الحالي، يمكنك أيضًا إنشاء موقع ويب صغير يمكن للمستخدمين تسجيل الدخول إليه باستخدام أسماء المستخدمين وكلمات المرور، ثم إضافة تعليمات DiscourseConnect البرمجية إلى هذا الموقع. سيكون ذلك أقل عملاً من إنشاء نسخة من Discourse.
شكرًا لك! يبدو أنني كنت أسيء فهم DiscourseConnect بشكل أساسي. كنت أعتقد أن صفحة تسجيل الدخول تبقى على Discourse، وأنها تتصل ببساطة بالخادم الخارجي. لم أكن على علم بأنه يتم توجيه المستخدم إلى صفحة تسجيل دخول مختلفة من اختيارنا بالكامل.
يبدو أن سوء فهمي لـ DiscourseConnect كان محور هذه المشكلة وكل الارتباك.
إذا كنت لا تهتم بإرسال Discourse للبريد الإلكتروني للإشعارات، فيمكنك جعل SSO الخاص بك يمنح Discourse اسم-مستخدم-لعبة@bogus.invalid كعنوان بريد إلكتروني.
قد يكون من الممكن بعد ذلك للمستخدمين إضافة عنوان بريد إلكتروني حقيقي ثانٍ ثم تبديل العنوان المزيف إلى العنوان الثانوي.
لم أفعل. كما قلت سابقًا، لم نكن نرغب في المضي قدمًا في نشر تجريبي حتى نعرف أن Discourse قابل للاستخدام. لذلك لم أجرب أي شيء في الواقع، حتى الآن كنا نقرأ فقط عن ميزاتك ونسأل هنا عندما لا تكون الأمور واضحة. هذا خبر رائع حقًا، لم أكن أدرك أننا نستطيع التحكم في الأمور إلى هذا الحد
بصراحة، يبدو من الصعب جدًا العثور على توثيق حقيقي لأي شيء خارج واجهة برمجة التطبيقات. على الأقل من منظور مستخدم لأول مرة.
لا يوجد شيء واضح في الصفحة الرئيسية لـ Discourse يربط بأي توثيق، وجميع الروابط في صفحة DiscourseConnect إما ترتبط بصفحات غير ذات صلة أو تعود إلى المنشور نفسه. محاولة البحث عن “توثيق Discourse” في محركات البحث تؤدي فقط إلى صفحات مثل https://meta.discourse.org/c/documentation/10، وهي مجرد فئة المنتدى الخاصة بها وليست صفحة توثيق حقيقية، و https://docs.discourse.org/ ولكن هذا هو توثيق واجهة برمجة التطبيقات ولا يحتوي على أي شيء يتعلق بميزات مثل DiscourseConnect على ما يبدو.
لقد ثبت أن محاولة العثور على هذه المعلومات بشكل عضوي أمر صعب.
هل هناك مكان واضح فاتني حيث يتم تغطية كل هذا؟ يبدو أن أقرب ما يمكنني العثور عليه هو فئة المنتدى، حيث توجد العديد من الأدلة / كيفية الاستخدام التي كتبها الموظفون وما شابه ذلك حول مواضيع مختلفة. لكن إعادة استخدام المنتدى لتوثيق نفسه لم يبدو صحيحًا بالنسبة لي؟ هل لا يوجد مصدر توثيق مخصص لميزات / أدوات Discourse كما هو الحال بالنسبة لواجهة برمجة تطبيقات Discourse؟
صحيح، هذا سينجح. كما ذكرنا عدة مرات، فإن استخدام بريد إلكتروني مزيف من موفر OAuth كان شيئًا توصلنا إليه قبل نشر هذا المنشور.
لكن هذا وحده لا يحل مشكلة “إذا رأى المستخدم في موجه تسجيل الدخول أنه يتم قبول رسائل البريد الإلكتروني، فسيحاول استخدامها وسيفشل بسبب وجود بريد إلكتروني مزيف”.
ومع ذلك، كان لدي سوء فهم لكيفية عمل DiscourseConnect. كنت أعتقد أن نموذج تسجيل الدخول لا يزال على ديسكورس، وأن ديسكورس يتواصل ببساطة مع موفر OAuth. لقد صحح لي @simon هذا الآن، لم أكن أدرك أنه ينقل المستخدم فعليًا خارج الموقع إلى نموذج تسجيل الدخول الخاص بنا. هذا وحده يحل تقريبًا جميع المشكلات التي كانت لدي. شكراً لك على الرغم من ذلك!
لم يكن أي شخص عملت معه غير راضٍ عن استضافة discourse.org. إذا كنت بحاجة إلى استضافة ذاتية لسبب ما، يمكنك تسجيل الدخول إلى https://dashboard.literatecomputing.com/ والانضمام إلى مجموعة “التجربة المجانية” واستخدام لوحة التحكم مجانًا (إذا لم تتمكن من معرفة كيفية الانضمام إلى مجموعة التجربة المجانية، فستحتاج على الأرجح إلى مزيد من الدعم مما أنا على استعداد لتقديمه). إذا كنت على استعداد لاستخدام Digital Ocean و mailgun، فما عليك سوى إدخال مفاتيح API واسم المضيف.
[اقتباس=“Michael Brown, post:15, topic:306489, username:supermathie”]
حتى إذا كنت ترغب فقط في تجربة الخدمة ولا تنوي الاستمرار في استخدام استضافتنا، فلا تتردد في بدء موقع تجريبي! لا نمانع!
[/اقتباس]
بصراحة، لم أفكر حتى في هذا الخيار! هذه نقطة جيدة ومن المحتمل أن نقوم بذلك لأغراض الاختبار.
لقد نظرت إلى خيارات الاستضافة الخاصة بك في وقت سابق اليوم، حيث سيكون ذلك أسهل من الاستضافة الذاتية، ولكن يبدو أنها خارج ميزانيتنا إلى حد كبير للأسف. لدينا أكثر من 200000 مستخدم، لذا فإن خطة “Basic” ليست خيارًا. لدينا أكثر من 5 موظفين، لذا فإن خطة “Standard” ليست خيارًا. وبصفتنا مشروعًا مفتوح المصدر (FOSS)، فإننا نعمل على التبرعات، وبالكاد نحقق ما يكفي لإبقاء الأضواء مضاءة ودفع تكاليف مطور بدوام كامل واحد، لذا فإن خطة “Business” بعيدة المنال.
ومع ذلك، فإن استخدام النسخة التجريبية لأغراض الاختبار فكرة رائعة، شكرًا لك! نحن بالفعل نستضيف معظم خدماتنا بأنفسنا على أي حال، حتى وصولًا إلى مثيل Mastodon الخاص بنا، لذا فإن استضافة Discourse ذاتيًا ليست عقبة كبيرة.
[اقتباس=“Michael Brown, post:15, topic:306489, username:supermathie”]
شكرًا لك على هذه الملاحظات - نحن نبذل جهدًا واعيًا لتحسين ذلك.
هل تمانع إذا اتصلنا بك لمناقشة المزيد؟
[/اقتباس]
بالطبع! يسعدني دائمًا المساعدة إذا استطعت، حتى لو كان ذلك بمجرد تقديم بعض الملاحظات. آمل ألا يبدو الأمر سلبيًا للغاية، حيث لم يكن هذا هو القصد لكي نكون واضحين.
إذا كنت مهتمًا، فنحن نقدم استضافة مجانية لبعض مشاريع FOSS… أعداد الموظفين لديك أعلى من حدودنا، ولكن الأشخاص الذين يتخذون القرار قد يتمكنون من التغاضي عن ذلك.
(لاحظ أن تعريفنا لـ “الموظفين” هنا هو “المسؤولون” + “المشرفون على مستوى الموقع”، وليس “الموظفون في الشركة المعنية” - سأكون فضوليًا لمعرفة تعريف الموظفين في ذهنك قبل هذا)
شكرًا لك! لقد فاتني هذا في صفحة الأسعار الخاصة بك. لقد عدت للتو للتحقق مرة أخرى وهي مدفونة في أسفل الصفحة سألقي نظرة على هذا وأتحدث مع فريقي!
يشمل تعريفنا لـ “الموظفين” في هذه الحالة دورين واسعين:
الأشخاص في فريق التطوير الأساسي لدينا (كمشروع مفتوح المصدر، يمكن أن يتقلب هذا، حيث قد يأتي الأشخاص ويذهبون، ولكن كان لدينا حوالي 5-10 مطورين نشطين على مر السنين في أي وقت معين)
فريق الإشراف لدينا (غير المطورين وأعضاء المجتمع الذين يشرفون على خدماتنا، مثل المباريات عبر الإنترنت وتنفيذ Miiverse الخاص بنا، بالإضافة إلى خادم Discord الخاص بنا). هذا يختلف أيضًا.
يمكننا الحد من هذا إلى 5 من المطورين لدينا فقط، مما يتناسب مع هذه الحدود، ولكنه سيتطلب منا تحديد من يحصل على حقوق كاملة على المنتدى ومن لا يحصل عليها. سيحد أيضًا من عدد الأشخاص القادرين على الإشراف على المنتديات (لقد قدمنا فريق إشراف خارج فريق التطوير من أجل تخفيف هذا العبء عنا في المقام الأول)
سأقوم بالتأكيد بطرح هذا الأمر على الأشخاص من جانبي وسنرى إلى أين ستسير الأمور!
سألقي نظرة على هذا وأتحدث مع فريقي!