مقدمة
كل شاشة إدخال في أودو تحتوي على مجموعة حقول؛ بعض الحقول يجب ملؤها يدوياً في كل مرة، بينما يمكن إعطاء أخرى قيمة مبدئية معقولة تجعل العمل اليومي أسرع. آلية القيم الافتراضية في أودو تبدو بسيطة لكنها تخفي طبقات من السلوك — لا سيما عند إعداد النماذج لفرق عمل متعددة أو عند تخصيص النظام.
سواءً كنت مستخدماً نهائياً تعدل نموذجاً عبر Odoo Studio أو مطوراً يبني وحدات مخصصة، فهم كيفية عمل القيم الافتراضية يوفر عليك وقت التصحيح ويمنع أخطاء إعدادات قد تظهر لاحقاً بشكل صامت.
هذا الدليل يشرح ماهية القيم الافتراضية في أودو، كيف يتم تطبيقها على مستوى ORM، متى نستخدم قيم ثابتة مقابل قيم ديناميكية، وكيفية ضبطها عبر Studio أو عبر برمجة بايثون.
ما المقصود بالقيمة الافتراضية في أودو
في بنية أودو، القيمة الافتراضية هي القيمة التي يحصل عليها الحقل عند إنشاء سجل جديد قبل أي تدخل من المستخدم. ليست قيداً إجبارياً بل نقطة انطلاق — تسمح للمستخدم بتغييرها لكنها تجعل النموذج أكثر فائدة حال فتحه.
معامل default متاح لمعظم أنواع الحقول في أودو: نصوص، أرقام صحيحة وعشرية، منطقية، تواريخ، حقول Many2one، Selection، وغيرها. يمكن أن يكون هذا المعامل قيمة ثابتة، لامبدا بايثون، أو إشارة إلى دالة؛ كل طريقة ملائمة لحالات استخدام مختلفة.
في Odoo Studio يظهر حقل القيمة الافتراضية ضمن خصائص الحقل كحقل بسيط يمكن للمدراء أو مستخدمي الأعمال تعبئته دون كتابة كود. هذه الطريقة هي الأكثر سهولة لتعزيز اتساق البيانات عبر واجهات المستخدم بدون تدخل المطور.
على مستوى قاعدة البيانات، القيم الافتراضية لا تُخزن في عمود الحقل بقدر ما تُعرف في تعريف النموذج البايثوني أو كسجلات داخل ir.default اعتماداً على طريقة الإعداد. عند إنشاء سجل جديد، يقرأ أودو هذه المصادر ويملأ الحقول تلقائياً قبل عرض النموذج للمستخدم.
كيف تعمل القيمة الافتراضية
عند فتح نموذج جديد، تستدعي المنصة default_get() على الموديل المعني. هذه الطريقة تجمع القيم الافتراضية وتعيد قاموساً يطابق أسماء الحقول بقيمها المبدئية، ثم تُستخدم هذه القيم لملء النموذج قبل التفاعل.
توجد أربع طرق رئيسية لتمثيل القيم الافتراضية في أودو، كل منها يخدم حاجة مختلفة.
القيم الثابتة
قيمة مضمّنة لا تتغير إلا بتعديل الإعداد، مثل جعل حقل منطقِي True افتراضياً أو وضع حالة Selection افتراضية مثل 'draft'. مناسبة لمعظم الحالات اليومية لأنها بسيطة وواضحة.
القيم الديناميكية عبر لامبدا أو دالة
دالة بايثون تُنفَّذ عند إنشاء السجل فتولّد قيمة بناءً على السياق—مثل المستخدم الحالي، تاريخ اليوم، أو إعدادات الشركة. هذا يسمح بأن تكون القيمة الافتراضية مرنة ومتصلة بحالة النظام وقت الإنشاء.
في تعريف الموديل البايثوني تبدو القيم الثابتة والديناميكية هكذا (تصميم نموذجي لتوضيح الفكرة):
مثال عملي في بايثون يوضّح ثلاث أنماط: قيمة ثابتة للاختيار، قيمة ديناميكية تشير للمستخدم الحالي، وقيمة تاريخية تعتمد على تاريخ اليوم. الفكرة الأساسية أن default يمكن أن يكون قيمة حرفية أو لامبدا أو دالة معقّدة.
القيم الافتراضية المعتمدة على السياق
يمكن تمرير قيم افتراضية عبر action context باستعمال مفاتيح بتنسيق default_field_name. هذا ما يحدث عند إنشاء سجل من داخل سجل مرتبط: أودو يمرّر مفتاح السياق ليمليء الحقول العلائقية تلقائياً — مثال شائع هو فتح مهمة جديدة من داخل مشروع فتجد حقل المشروع مُعَبَّأ.
القيم الافتراضية على مستوى المستخدم عبر ir.default
أودو يوفّر أيضاً إمكانية ضبط قيمة افتراضية خاصة بمستخدم معين عن طريق سجلات ir.default. أي مستخدم يملك إعداداً شخصياً له الأولوية على القيمة المعرفة في الكود، مما يتيح تفضيلات عمل مختلفة بين أعضاء الفريق.
ترتيب الأولويات
عندما تأتي القيم الافتراضية من مصادر مختلفة، أودو يطبق أولوية محددة: أولاً قيم ir.default الخاصة بالمستخدم، ثم قيم ir.default الخاصة بالشركة، ثم القيمة المعرفة في الموديل البايثوني. كذلك قيم السياق التي تُمرَّر وقت التشغيل يمكن أن تتجاوز الافتراضات المعرفية. معرفة هذا الترتيب تشرح لماذا لا ترى دائماً القيمة المتوقعة عند فتح نموذج جديد.
سيناريوهات أعمال عملية
القيم الافتراضية منتشرة في كل وظائف أودو؛ فيما يلي أمثلة عملية تغطي سيناريوهات أعمال حقيقية.
سجل المبيعات: مسؤول المبيعات الافتراضي على العملاء المتوقعين
عند إدخال فرصة جديدة في CRM، يُعَيَّن عادةً الحقل 'المسؤول' إلى المستخدم الحالي تلقائياً. هذه خطوة بسيطة لكنها تقلّل عدد السجلات غير المعينة وتزيد تقبّل الفريق للنظام لأن كل مستخدم يرى سريعاً ما يخصّه.
المبيعات: شروط الدفع الافتراضية في الأوامر
عند فتح أمر بيع لعميل، تُملأ حقول مثل قائمة الأسعار وشروط الدفع بناءً على إعدادات العميل. عميل محدد بشروط Net 30 سيحصل على نفس الشروط مسبقاً في كل أمر، مما يقلّل الأخطاء ويضمن تطبيق الشروط المتفق عليها.
المخزون: المواقع الافتراضية في التحويلات
عند إنشاء تحويل داخلي أو ضبط مخزون، يتم تعبئة مواقع المصدر والوجهة وفق إعدادات المستودع. عامل المستودع الذي يعمل داخل نفس المنطقة سيجد الموقع الصحيح محدداً سلفاً، الأمر الذي يسرّع العملية ويقلّل المخاطر أثناء العمل تحت ضغط.
المحاسبة: السجل الافتراضي في القيود
عند إنشاء فاتورة عميل أو سند مورد، يختار أودو السجل الملائم اعتماداً على نوع القيد وإعدادات الشركة. المحاسب لن يحتاج لاختيار دفتر الشراء يدوياً في كل مرة لأن النظام يحدده ديناميكياً بناءً على التكوين.
المشروع: المرحلة الافتراضية للمهام الجديدة
عند إنشاء مهمة داخل مشروع، تبدأ عادة في المرحلة الأولى المُعرَّفة في إعدادات كانبان للمشروع. إذا أُنشئت المهمة من زر داخل مشروع معين، فالسياق يملأ حقول المشروع وأحياناً المسؤول مباشرةً، ما يجعل إدارة المهام أكثر انتظاماً.
إنشاء أو تخصيص القيم الافتراضية
ثلاث طرق رئيسية لوضع القيم الافتراضية: واجهة بدون كود عبر Studio، تعديل بايثون تقني، أو إنشاء سجلات ir.default بآلية تلقائية.
استخدام Odoo Studio (بدون كود)
يتيح Studio واجهة مرئية لتعيين قيمة افتراضية لأي حقل في النماذج. خطوات بسيطة تمكّن المستخدمين من ضبط قيمة ابتدائية دون الحاجة لمطور.
- افتح واجهة Studio على النموذج المستهدف
- انقر على الحقل الذي تريد تغييره
- ابحث في لوحة خصائص الحقل عن إدخال القيمة الافتراضية
- أدخل أو اختر القيمة التي تريدها كنقطة بداية
- احفظ واخرج من Studio
Studio يخزن الإعداد كسجل في ir.default ويطبقه على مستوى الشركة ما لم يقم المسؤول بتحديد نطاق مستخدم. هذه الطريقة ملائمة للقيم الثابتة على حقول Selection وBoolean وChar وInteger، وللـ Many2one يمكن اختيار سجل موجود من القائمة—حل عملي لتحسين النماذج بدون كتابة كود.
ملاحظة هامة: تغيير الافتراض عبر Studio لا يعدّل السجلات الموجودة مسبقاً؛ سيؤثر فقط على السجلات الجديدة التي تُنشأ بعد التغيير.
استخدام بايثون في التخصيص التقني
في التخصيص التقني نعرّف الافتراضات مباشرة في تعريف الحقل بالبايثون، ما يمنحنا تحكم كامل بالقيم الثابتة واللامبدا والدوال المعتمدة على وقت التشغيل—النهج المفضل عندما تحتاج الافتراضات أن تتفاعل مع المستخدم الحالي أو تاريخ اليوم أو إعدادات الشركة.
فيما يلي مثال نموذجي يوضّح أنواع مختلفة من الافتراضات التي قد تضيفها في وحدة مخصصة:
الشكل العام يتضمن: قيمة منطقية افتراضية، اختيار افتراضي، ودالة تعيد قيمة نصية من إعدادات التكوين. الهدف إظهار كيف تُعرّف افتراضات معقدة يمكن قراءتها من إعدادات أو بيئة النظام.
هذا الأسلوب يتبع قواعد تعريف الحقول في أودو ويعمل عبر جميع أنواع الحقول. الافتراض المبني على دالة مفيد عندما يتطلب الأمر منطقاً يتجاوز لامبدا بسيطة.
إنشاء سجلات ir.default برمجياً
يمكن أيضاً إنشاء أو تحديث سجلات ir.default عبر XML-RPC أو عن طريق ملفات بيانات تُحمّل مع الوحدة. هذا مفيد عند توزيع إعدادات افتراضية مع تثبيت الوحدة بحيث يتم تهيئة سلوك النظام تلقائياً.
استخدام هذه الطريقة أقل شيوعاً في التطوير اليومي لكنه مفيد عند بناء وحدات قابلة للتثبيت تحتاج لضبط افتراضات معقولة ضمن روتين الإعداد.
أفضل ممارسات للقيم الافتراضية في أودو
ضع افتراضات للحقول الإلزامية
إذا كان الحقل إجباريًا، امنحه افتراضاً عملياً حيثما أمكن لتقليل الأخطاء عند الحفظ. الجمع بين required=True وقيمة افتراضية مناسبة يسهّل على المستخدمين إدخال السجلات دون توقف.
استخدم لامبدا للتواريخ الافتراضية
لا تقم بتجميد تاريخ معين كقيمة افتراضية؛ استخدم lambda تُعيد fields.Date.today() حتى تكون القيمة دائماً تاريخ الإنشاء. تاريخ ثابت سيصبح خاطئاً فورياً بعد نشر الكود.
اجعل منطق الافتراضات خفيفاً
دوال الافتراض تعمل عند كل إنشاء سجل؛ لذلك تجنّب استعلامات ثقيلة أو استدعاءات خارجية أو عمليات حسابية مكثفة. إذا احتجت لعمل معقّد، فكّر باستخدام onchange أو حقول محسوبة تُشغَّل لاحقاً بدلاً من تحميل default.
استخدم افتراضات السياق لتدفق التنقل
عند بناء أزرار أو إجراءات تفتح نماذج جديدة، مرّر مفاتيح default_field_name عبر action context بدلاً من الاعتماد على افتراضات ثابتة في الموديل. هذا يتماشى مع سلوك أودو الأصلي ويجعل التخصيص أكثر اتساقاً.
اختبر الافتراضات عبر ملفات تعريف مستخدمين متعددة
افتراضات تشير self.env.user أو self.env.company قد تتصرف بشكل مختلف بحسب المستخدم أو الشركة. اختبر على حسابين مختلفين وعلى إعدادات شركة متعددة لتتأكد من أن السلوك صحيح لجميع الأدوار.
الأخطاء الشائعة
استخدام كائن قابل للتغيير كقيمة افتراضية
قاعدة بايثون الكلاسيكية تنطبق هنا: لا تضع default=[] أو default={} لأن هذه الكائنات تُشارك بين كل السجلات. استخدم default=lambda self: [] لتوليد كائن جديد لكل سجل.
الافتراضات لا تفعّل onchange
ضبط قيمة افتراضية لا يطلق دوال onchange. إذا كان لديك منطق يعتمد على onchange لملء حقول أخرى، فالقيمة الافتراضية تتجاوز ذلك ولن تُشغّل سلسلة التحديثات. لإجبار التشغيل عند البداية يجب استدعاء onchange يدوياً في override لـ default_get أو إعادة تصميم المنطق.
تعارض الافتراضات بين ir.default وتعريف الموديل
عند وجود افتراض مُعرَّف في الكود وآخر عبر Studio/ir.default فإن ir.default يتفوّق. هذا سبب شائع للاختلافات غير المتوقعة في القيم، خصوصاً بعد تعديل عبر Studio يغيّر سلوكاً كان مطور قد حدده في الكود.
الافتراض لا يعني أن الحقل مطلوب
وجود قيمة افتراضية لا يجعل الحقل إجباريّاً تلقائياً؛ المستخدم يمكنه حذف القيمة وسيُحفظ الحقل فارغًا. إن أردت ضمان وجود قيمة دائماً، اجعل الحقل required=True بالإضافة إلى وجود افتراض عملي.
تضمين معرفات مستخدم أو شركة ثابتة
استخدام default=1 للإشارة لمستخدم أو شركة عبر ID رقم ثابت هشّ ويكسر عند نقل البيانات بين بيئات ذات قواعد بيانات مختلفة. استخدم إشارات ديناميكية مثل lambda تعيد self.env.company.id أو self.env.ref('module.xml_id').id.
خاتمة
القيم الافتراضية ميزة صغيرة لكنها فعّالة في نموذج بيانات أودو: تقلّل الإدخال اليدوي، توجه المستخدمين للاختيار الصحيح، وتجعل النماذج أسهل في الاستخدام. سواء ضبطتها عبر Studio أو عبر بايثون، فهم آلية عملها يساعد في بناء تنصيبات أودو أكثر ملاءمة للفِرق.
نقاط أساسية يجب تذكّرها: الافتراضات تعمل فقط عند إنشاء السجل، لا تشغّل onchange، وتُحلّ المصادر المتعددة وفق أولوية محددة. كما يجب تجنّب استخدام قوائم أو قواميس مشتركة دون لامبدا.
الاهتمام الصحيح بالافتراضات غالباً ما يكون الفارق بين نموذج سلس يشعر به المستخدمون ونموذج يسبب إحباطاً في كل مرة يُنشأ فيها سجل جديد. استثمار صغير هنا يعود بفائدة مستمرة.
في Dasolo نساعد الشركات على تنفيذ وتخصيص وتحسين أودو ليتناسب مع سير عملها الفعلي. إذا احتجت مساعدة في ضبط قيم افتراضية، بناء حقول مخصصة، أو تصميم نموذج بيانات يعمل فعلاً لفريقك، نحن جاهزون لدعمك. تواصل معنا ودعنا نناقش تنفيذ أودو الخاص بك.