دعم أودو: الإبلاغ عن الأعطال وتحديد أولويتها ومعالجتها

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

يتناول هذا الدليل الإبلاغ عن الأعطال واستعادة العمل بطريقة منضبطة. جرى التحقق من مراجع المنصة في 10 نوفمبر 2026 بالرجوع إلى وثائق أودو 19. تعتمد الأدوات المتاحة والمسؤوليات على الاستضافة والصلاحيات واتفاقية الدعم الخاصة بك.

1. وجّه المشكلة إلى الجهة المسؤولة

حدّد ما إذا كانت العملية المتأثرة تستخدم تطبيقًا قياسيًا أو إضافة مخصصة أو موصلًا خارجيًا أو بنية تحتية تديرها مؤسستك. سجّل إصدار أودو، وما إذا كانت قاعدة البيانات مستضافة على Odoo Online أو Odoo.sh أو لدى جهة أخرى.

تميّز اتفاقية اشتراك أودو Enterprise بين دعم الوظائف القياسية والإضافات المشمولة بالعقد، وبين المساعدة الأخرى في التطوير أو التخصيص. وتوضح أيضًا العمل من خلال أودو أو أحد شركائه. راجع اتفاقيتك الفعلية وجهة الدعم المحددة فيها، ولا تفترض أن جميع الإضافات تتمتع بالتغطية نفسها.

تتضمن قائمة المسؤوليات العملية جهة اتصال المورد، وشريك التطبيق، والمسؤول عن صيانة الإضافات المخصصة، ومدير الاستضافة، وصاحب العملية داخل المؤسسة. عيّن منسقًا واحدًا يتابع العطل حتى عند مشاركة عدة موردين في التحقيق. تأكيد استلام الطلب، وتوفير حل مؤقت، وتنفيذ تصحيح دائم مراحل مختلفة؛ اتفق على موعد التحديث التالي دون افتراض موعد غير مؤكد لحل المشكلة.

2. اجمع معلومات محددة ومفيدة

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

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

3. حدّد الأولوية وفق الأثر والبدائل المتاحة

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

وثّق أي حل مؤقت وحدوده. قد يحفظ تسجيل الطلب يدويًا معلومات الاستفسار، لكنه يتطلب مطابقة لاحقة؛ وقد يؤدي تعطيل أحد ضوابط النظام إلى أخطاء غير مقبولة. ينبغي لصاحب العملية اعتماد البدائل التشغيلية وتحديد من سيتولى تسوية المعاملات المتراكمة.

4. أعد إظهار المشكلة في بيئة اختبار مناسبة

تستخدم بيئات ما قبل الإنتاج (Staging) في Odoo.sh نسخة من بيانات الإنتاج، بينما تستخدم بيئات التطوير قواعد بيانات جديدة وبيانات تجريبية. وتشرح وثائق عمليات البناء في Odoo.sh أيضًا الوصول إلى السجلات ومعلومات إصدارات الشيفرة. أرفق مرجع البناء أو التغيير المناسب عندما تظهر المشكلة بعد نشر تحديث.

في Odoo Online، يوضح دليل إدارة قواعد البيانات إنشاء نسخة مكررة للاختبار. لا تلغي بيئة الاختبار متطلبات الخصوصية؛ فقد تتضمن نسخة الإنتاج معلومات حقيقية عن العملاء، ولذلك يجب الإبقاء على ضوابط الوصول اللازمة.

تسرد إرشادات قواعد البيانات المُحيَّدة للاختبار إجراءات خارجية يجري تعطيلها، مثل البريد الصادر ومزودي الدفع. تحقّق من حالة بيئة الاختبار قبل إعادة إظهار العطل، بما في ذلك أي تكامل مخصص. يجب ألا يؤدي التحقيق دون قصد إلى إنشاء طلبات أو إرسال رسائل أو تحصيل مدفوعات فعلية.

5. اختبر التصحيح وخطّط للاستعادة

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

لا يعني هذا المثال أن إضافة مخصصة هي سبب كل خطأ مشابه. إنه يوضح الأدلة اللازمة للتمييز بين تزامن حدثين وإثبات السبب. احتفظ بخطوات إعادة المشكلة الأصلية حتى يستطيع صاحب العملية تكرار الاختبار.

قبل تغيير بيئة الإنتاج، حدّد مسؤول النشر والنسخة الاحتياطية المعتمدة وصاحب قرار الرجوع عن التغيير والانقطاع المتوقع. الرجوع إلى شيفرة سابقة واستعادة قاعدة بيانات إجراءان مختلفان في أثرهما. قد تؤدي استعادة قاعدة أقدم إلى فقد المعاملات اللاحقة، لذلك يجب أن تعالج خطة الاستعادة النشاط الذي وقع بين النسخة المستعادة ووقت التنفيذ.

6. أغلق الطلب بعد التحقق من النتيجة

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

للمساعدة في تحديد المسؤوليات، اطّلع على خدمات أودو لدى لافا أو أرسل استفسارًا يتضمن الإصدار وترتيب الاستضافة ووصفًا غير حساس للعملية المتأثرة.