نسخ قاعدة بيانات Odoo: ما الذي تعطّله أولاً

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

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

ما الذي يمكن أن تفعله النسخة في العالم الحقيقي

قبل أن تقرر ما الذي تعطّله، اكتب قائمة بكل ما يخرج من النظام فعلاً. في تطبيق نموذجي في المنطقة، تبدو القائمة عادةً هكذا:

• البريد الصادر: تذكيرات الدفع، ومتابعات عروض الأسعار، وتجديدات الاشتراكات، والحملات التسويقية، كلها تخرج عبر خادم البريد المضبوط إلى عملاء حقيقيين.
• البريد الوارد: إذا احتفظت النسخة بخادم البريد الوارد نفسه، فستجلب الرسائل من الصندوق نفسه. ويعلّم Odoo الرسائل التي جلبها كمقروءة أو يحذفها من الخادم بحسب طريقة الإعداد، فقد لا يرى الإنتاج أبداً الردود التي التقطتها النسخة أولاً.
• الإجراءات المجدولة: كل مهمة cron تعمل في الإنتاج تبدأ العمل في النسخة أيضاً: الفواتير المتكررة، والتذكيرات، ومزامنة البيانات، والإجراءات الآلية المرتبطة بالوقت.
• مزودو الدفع: مفاتيح API الحقيقية تنتقل مع قاعدة البيانات. أي عملية دفع تجريبية على النسخة هي خصم حقيقي، والمهمة المجدولة التي تخصم من وسائل الدفع المحفوظة، مثل تجديد الاشتراكات، قد تخصم من العميل نفسه مرتين، مرة من كل قاعدة بيانات.
• الفوترة الإلكترونية: إذا كانت وحدات التوطين الرسمية في Odoo مربوطة بـ ZATCA في السعودية أو ETA في مصر، فقد تصل الفاتورة المرحّلة على النسخة إلى الجهة الضريبية كمستند ضريبي حقيقي. وهذا أصعب خطأ في القائمة، لأن تصحيحه يمر عبر إجراءات الجهة نفسها، لا عبر حذف سجل.
• تكاملات أخرى: شركات الشحن التي تصدر بوالص حقيقية، ومزامنة الحسابات البنكية، ومزامنة التقويم مع Google أو Outlook، وقواعد الأتمتة التي تستدعي روابط خارجية (webhooks).

التحييد المدمج في Odoo

منذ الإصدار 16، يتضمن Odoo خطوة مصممة لهذا الموقف بالضبط اسمها التحييد (neutralization). يمكن تشغيلها من سطر الأوامر عبر odoo-bin neutralize، كما يعرضها مدير قواعد البيانات خياراً عند نسخ قاعدة بيانات أو استعادتها.

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

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

فحص من خمس دقائق على أي نسخة

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

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

أعد التفعيل عن قصد

للتحييد ثمن: النسخة المحيّدة بالكامل لا تستطيع اختبار المسارات التي تخرج من النظام. فلا يمكنك التحقق من قالب بريد جديد للفواتير، أو من صفحة الدفع، أو من الإرسال إلى ZATCA، ما دامت الثلاثة معطّلة.

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

مكان النسخة مهم أيضاً

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

لهذا تتضمن الاستضافة المُدارة بيئات staging وsandbox بدلاً من أن يبنيها كل فريق بنفسه. توفر استضافة Plemo المُدارة بيئات staging وsandbox إلى جانب النسخ الاحتياطية الآلية والاسترجاع إلى نقطة زمنية محددة والمراقبة، كما تُعرض التخصيصات المبنية عبر Plemo في بيئة تجريبية قبل أن يصل أي شيء إلى الإنتاج. وأياً كانت المنصة التي تستخدمها، فقائمة الفحص أعلاه قصيرة بما يكفي لتشغيلها على كل نسخة تنشئها.