مقدمة
إذا سبق أن حاولت حفظ نموذج في أودو وانتبهت إلى حقل تحول لونه إلى الأحمر، فقد واجهت آلية "الحقل المطلوب". هذه الخاصية البسيطة لكنها فعالة تعمل كحاجز أول يحافظ على اكتمال المعلومات داخل النظام ويمنع تسجيل سجلات ناقصة.
سواء كنت تضبط أودو لفريق مبيعات، تبني نموذجًا مخصصًا، أو تجري تطويرًا تقنيًا على النظام، فمعرفة متى وكيف تُطبّق خاصية required تساعدك على تصميم تدفقات عمل أقل عُرضة للأخطاء.
هذا الدليل يشرح سلوك الخاصية داخل إطار عمل أودو، طرق تفعيلها عبر Odoo Studio أو في كود بايثون، متى تستعملها، وأين تكمن المخاطر التي تستدعي الحذر.
ما هي الخاصية "مطلوب" في أودو
في أودو، الخاصية required تُعرَف كقيد على مستوى الحقل يمنع حفظ السجل ما لم يُزوَّد الحقل بقيمة. تنطبق هذه القاعدة على معظم أنواع الحقول: نصوص، أرقام، قوائم اختيار، many2one، تواريخ وغير ذلك.
هي جزء أساسي من نموذج بيانات أودو وغالبًا ما تكون أول وسيلة لتفادي بيانات غير مكتملة أو غير متسقة عند إجراء تخصيصات للنظام.
كيف يظهر ذلك للمستخدمين
في واجهة أودو، تُميَّز الحقول المطلوبة عن الحقول الاختيارية بصريًا. أثناء تعديل نموذج، تُعرض إشارة مرئية على الحقول المطلوبة، وإذا حاول المستخدم الحفظ بدون إدخال قيمة، يقوم النظام بتظليل الحقل وإظهار رسالة تنبيه.
هذا السلوك موحَّد في الواجهة الوبّية ويمنح المستخدمين تغذية راجعة فورية تقلل من احتمالية إدخال سجلات ناقصة.
ثابت أم مشروط؟
ثمة طريقتان لجعل الحقل مطلوبًا في أودو. الأولى: جعله مطلوبًا بشكل دائم (static) — لا يمكن حفظ السجل بدونه. الثانية: جعله مطلوبًا بشكل ديناميكي — يصبح مطلبًا فقط عند تحقق شروط معينة اعتمادًا على قيم حقول أخرى في نفس السجل.
كلا الطريقتين مستخدمتان في تخصيص أودو، والاختيار يعتمد على منطق العمل لديك.
كيف تعمل الخاصية
فهم كيفية تطبيق الخاصية على المستوى الفني يساعدك على توظيفها بصورة صحيحة وحل المشكلات حين تظهر.
تطبيق القيد على مستوى التطبيق
تفصيل مهم يجهله بعض المستخدمين: تحقق خاصية required يتم في طبقة التطبيق (application level)، وليس بشكل تلقائي على مستوى قاعدة البيانات. أي أن فحص القيم يقوم به ORM الخاص بأودو قبل وصول البيانات إلى PostgreSQL.
بشكل افتراضي، إضافة required=True لا تضيف قيد NOT NULL في عمود قاعدة البيانات. فالتحقق يحدث في بايثون داخل طبقة ORM لأودو.
سيترتب على ذلك أن أي إدخال يتم مباشرة إلى قاعدة البيانات دون المرور عبر أودو لن يخضع لهذا القيد. لذلك احرص دائمًا على التفاعل مع بيانات أودو عبر ORM أو واجهات API للاستفادة من الضوابط.
ماذا يحدث عند خرق القيد؟
عند محاولة حفظ نموذج تاركًا حقلًا مطلوبًا فارغًا، يحدث أمران رئيسيان:
- يُظهر النظام الحقل باللون الأحمر ويرفق رسالة تحقق
- وتُمنع عملية الحفظ إلى أن يُملأ الحقل
وعند استدعاء الحفظ برمجيًا (مثلًا عبر XML-RPC أو إجراء سيرفر)، يرفع أودو استثناء ValidationError يوضح أي حقل مطلوب مفقود.
المطلوب الديناميكي عبر التعبيرات
يمكن جعل required مشروطًا عبر تعابير في مستوى العرض (view). في الإصدارات الأقدم من أودو يتم ذلك باستخدام attrs في XML العرضي:
على سبيل المثال، تستطيع ضبط قواعد تجعل حقل تاريخ التسليم مطلوبًا فقط إذا كان نوع الطلب من فئة التوصيل.
في أودو 17 وما بعدها، صيغ العرض تبسّطت ويمكن كتابة شرط required مباشرة على وسم الحقل في الـ XML:
وبذلك يصبح الكود في العرض أكثر وضوحًا عند تعيين شروط تظهر الحقل كمطلوب اعتمادًا على قيمة حقل آخر.
هذه القواعد تقيم في طبقة العرض فقط، أي أنها تنطبق أثناء تحرير السجل من خلال ذلك الـ view المحدد، بينما required على مستوى الموديل (model-level required=True) يظل قيدًا صارمًا بغض النظر عن طريقة الوصول إلى السجل.
التفاعل مع ORM وواجهات برمجة التطبيقات
عندما تستدعي create() أو write() في ORM، يقوم النظام بالتحقق من جميع الحقول الموسومة بـ required=True قبل تنفيذ عملية قاعدة البيانات. إن كان الحقل المَطلوب مفقودًا أو قيمته False، يطرح أودو ValidationError.
ينطبق نفس المبدأ عند إنشاء سجلات عبر XML-RPC أو أي واجهة برمجة: الحقول المطلوبة في تعريف الموديل يجب أن تتوافر داخل بيانات الإنشاء وإلا فإن الطلب سيفشل.
حالات استخدام عملية
أمثلة عملية من الواقع
1) إدارة العملاء: فرض تصنيف العميل على العملاء المحتملين
مثلًا فريق المبيعات قد يريد تصنيف كل lead حسب شريحة العميل قبل وضعه في خط المبيعات. بدون قيد مطلوب يتجاهل المندوبون غالبًا هذه الخطوة، ما يجعل تحليل القنوات حسب الشريحة مستحيلاً لاحقًا.
بجعل حقل "شريحة العميل" مطلوبًا على نموذج الـ lead تضمن أن البيانات تُجمع عند نقطة الإدخال، وإلا لا يُسمح بالحفظ.
2) المبيعات: إجبار وجود عنوان توصيل في الطلبات
للشركات التي تشحن بضائع مادية، يكون عنوان التوصيل عنصرًا أساسيًا. في بعض إعدادات أودو لا يكون هذا الحقل مطلوبًا افتراضيًا، فيمكن تأكيد طلب بدون عنوان.
بجعل حقل عنوان التوصيل مطلوبًا على أمر المبيعات تتجنب تأكيد طلبات ناقصة المعلومات، مما يقلل الأخطاء في قسم التنفيذ واللوجستيات.
3) المستودعات: رقم الدفعة أو السيريال عند الاستلام
في صناعات خاضعة للوائح مثل الغذاء أو الأدوية، تتطلب تتبع أرقام الدُفعات أو السيريالات أثناء الاستلام. أودو يدعم هذا عبر إعداد التتبع على المنتج، ما يفرض تسجيل رقم الدفعة في حركات المخزون.
ولحقول مخصصة مثل مرجع جودة على استمارات الاستلام، يجعل وضعها كمطلوبة التأكد من أن فريق المستودع يسجل المعلومات دائمًا أثناء عملية الاستلام.
4) المحاسبة: مركز التكلفة على فواتير الموردين
تحتاج فرق المالية أحيانًا أن تُسجل كل مصروفات ضمن مركز تكلفة لقياس الميزانية. إن تُرك هذا الحقل فارغًا فستتولد فجوات في التقارير المالية.
إضافة many2one مطلوب يشير إلى نموذج مراكز التكلفة على فاتورة المورد يضمن عدم ترحيل الفاتورة بدون هذا التصنيف؛ تكامل بسيط لكنه ذي تأثير كبير على جودة البيانات.
5) الموارد البشرية: نوع العقد قبل إتمام التوظيف
في عمليات التوظيف، قد ترغب الموارد البشرية بتسجيل نوع العقد قبل إكمال ملف الموظف. حقل مطلوب على نموذج الموظف يمنع حفظ سجل ناقص أثناء فترات الاندفاع في عمليات الانضمام.
إنشاء الحقل أو تخصيصه
طريقتان لعمل الحقول المطلوبة
هناك طريقتان أساسيتان لجعل الحقل مطلوبًا: استخدام Odoo Studio لنهج بدون كود، أو كتابة حقل في بايثون لمنحك تحكّمًا كاملاً.
استخدام Odoo Studio
Odoo Studio أداة مدمجة تتيح تعديل النماذج بسهولة. عند اختيار حقل في وضع الاستوديو ستجد مفتاح تبديل "مطلوب" في خصائص الحقل؛ تفعيله يجعل الحقل مطلوبًا على مستوى النموذج بسرعة ودون كتابة كود.
لكن حدوده تظهر عندما تحتاج لمتطلبات ديناميكية تعتمد على حقول أخرى؛ حينها ستضطر لتعديل XML العرضي أو اتباع نهج تقني.
النهج التقني: حقول بايثون
في موديل مخصص، يكفي إضافة required=True لتعريف الحقل في ملف البايثون. هذا النمط هو المعتاد في تطوير حقول أودو بايثون ويوفر قيدًا على مستوى الموديل.
مثال عملي على تعريف حقل تحديد أو many2one مع required=True يضمن تطبيق القيد بغضّ النظر عن العرض المستخدم لإنشاء السجل.
بهذه الطريقة يصبح القيد صارمًا على المستوى النموذجي ويطبق مهما كانت واجهة الإدخال.
المطلوب الديناميكي في XML العرضي
إذا أردت أن ينطبق القيد فقط في ظروف معينة، اضفه في مستوى العرض بدلًا من الموديل. في الإصدارات القديمة يتم ذلك عبر attrs في وسم الحقل.
مثال: جعل مركز التكلفة مطلوبًا فقط عندما يكون نوع الطلب من فئة معينة.
في الإصدارات الأحدث تصبح الكتابة أبسط وتُكتب التعابير مباشرة كما شرحنا أعلاه.
في أودو 17 يمكنك التعبير عن شرط required على وسم الحقل نفسه لتصبح الشروط أوضح في العرض.
تذكّر أن هذه الضوابط تعمل أثناء تحرير السجل من ذلك العرض فقط؛ هي أخف من القيد على مستوى الموديل.
إنشاء الحقول المطلوبة عبر API
عبر XML-RPC يمكنك عند إنشاء حقول برمجيًا تحديد required ضمن بيانات تعريف الحقل على ir.model.fields، ما يجعل العملية قابلة للأتمتة أثناء نشر التخصيصات.
من خلال استدعاء create على ir.model.fields وإدراج required=True يمكنك إنشاء الحقل وتفعيل القيد ضمن خطوة واحدة.
هذا مفيد في سيناريوهات نشر آلي حيث تُنشأ الحقول برمجيًا كجزء من عملية الإعداد.
أفضل الممارسات
نصائح عملية تجعل التطبيق أسهل
1) اجعل الحقول مطلوبة فقط عندما تكون ضرورية بالفعل
إفراطك في فرض الحقول المطلوبة واحد من الأخطاء المتكررة؛ إن لم تكن المعلومة متاحة عند نقطة الإدخال سيُلجأ المستخدمون إلى حلول وسطية مثل إدخال قيم مكانية تكسر جودة البيانات.
قبل تفعيل القيد اسأل: هل تتوافر هذه المعلومة دائمًا عند الإدخال؟ إن لم تكن الإجابة بنعم واضحة، فكّر في جعلها مطلوبة عند مرحلة لاحقة أو اعتماد سلوك ديناميكي.
2) فرض القيم بحسب المراحل أفضل من جعلها مطلقة
في سير عمل متعدد المراحل غالبًا ما يكون من الأنسب فرض الحقول عند الانتقال إلى مرحلة محددة بدلاً من فرضها منذ البداية؛ يمكن تحقيق ذلك بقواعد بايثون أو إجراءات تلقائية تتحقق من القيم عند تغيير المرحلة.
هذا الأسلوب أقدر على التكيف وأسهل على المستخدمين من فرض كل شيء منذ البداية.
3) أربط الحقول المطلوبة بقيم افتراضية عند الإمكان
إن كان لحقل مطلوب قيمة افتراضية منطقية في معظم الحالات، عيّن default لتخفيف العبء عن المستخدمين مع الحفاظ على عدم ترك الحقل فارغًا.
4) استخدم required على مستوى الموديل للبيانات الحرجة
للمعلومات الحرجة (كالمعرفات المحاسبية أو بيانات تنظيمية) طبق القيد على مستوى الموديل في بايثون حتى لا يُتَجَاوَز عن طريق واجهات أخرى أو استيراد بيانات.
5) أبلغ المستخدمين بالتغييرات
إضافة حقول مطلوبة إلى نماذج مستخدمة بالفعل قد يفاجئ العاملين. أخطر الفريق قبل النشر خصوصًا إذا كانت السجلات الحالية ستفشل في التحقق عند تحريرها لاحقًا.
6) اختبر حالات الإدخال الفارغة والجزئية
قبل نشر الحقول المطلوبة اختبر المسارات ببيانات ناقصة ومن خلال الواجهة والـ API وأي إجراءات أو تكاملات آلية. هذه خطوة أساسية لتجنب مشاكل ما بعد الإطلاق.
الأخطاء الشائعة
الأخطاء التي ستقابلك كثيرًا
مشكلة 1: جعل حقل مطلوب على موديل يحتوي سجلات سابقة
إذا أضفت required=True لحقل في موديل يحتوي بالفعل سجلات دون قيمة لذلك الحقل، سيواجه المستخدمون صعوبات عند تحرير هذه السجلات لأن الحفظ سيُمنع حتى تُملأ الحقول.
قبل نشر قيد جديد على موديل قائم، تحقق من وجود قيم للحقل في السجلات الحالية وقم بترحيل البيانات إن لزم.
مشكلة 2: الخلط بين قيد العرض وقيد الموديل
وضع الحقل كمطلوب في العرض (Studio أو XML) لا يفرض القيد على مستوى الموديل؛ إنشاء السجل عبر API أو عرض آخر قد يتجاوز هذا القيد.
إذا أردت قيدًا صارمًا ضع required=True في تعريف الحقل ببايثون لتجنب سوء الفهم ومشاكل الجودة لاحقًا.
مشكلة 3: الحقول المطلوبة في إجراءات آلية أو مجدولة
عندما تنشئ إجراءات آلية سجلات برمجيًا يجب أن تزودها بقيم الحقول المطلوبة. إذا أُضيف حقل مطلوب بعد كتابة الإجراء فسوف يفشل أو يقدم أخطاء مبهمة.
راجع الشيفرات والإجراءات الآلية بعد إضافة أي حقل مطلوب على موديل موجود.
مشكلة 4: استيراد بيانات تفتقد الحقول المطلوبة
عند الاستيراد عبر CSV أو أداة الاستيراد، أي حقول مطلوبة مفقودة ستمنع الاستيراد؛ هو السلوك الصحيح لكنه قد يفاجئ من اعتادوا استيراد بيانات جزئية.
تأكد من تضمين كل الحقول المطلوبة في قوالب الاستيراد ووثّق القوائم المطلوبة لفرق البيانات.
مشكلة 5: استخدام required بدل قيود بايثون للتحقق المعقّد
الخاصية required تتحقق فقط من عدم فراغ الحقل ولا تفحص صحة المحتوى أو علاقة الحقول ببعضها. للتحققات المعقدة (مثلاً التأكد من أن تاريخ مستقبلي أو التناسق بين حقلين) استخدم @api.constrains في بايثون.
محاولة حشر منطق العمل المعقّد داخل required وحدها تؤدي إلى إعدادات جامدة يصعب صيانتها.
خلاصة
الخلاصة
خصيصة الحقول المطلوبة أداة بسيطة لكنها ذات أثر كبير على جودة بيانات أودو. استخدامها الصحيح يضمن تسجيل المعلومات الحرجة في الوقت المناسب؛ وسوء استخدامها يولد إحباطًا وحلولًا وسطية تُضعف مصداقية قواعد البيانات.
المهم أن تميز بين القيد على مستوى الموديل والقيد على مستوى العرض، وأن تختار بعناية الحقول التي تستحق فرضًا دائمًا، وأن تخطط لتأثير هذا الفرض على الأتمتة والتكاملات.
هل تحتاج مساعدة في تنفيذ أودو؟
في شركة Dasolo نعمل مع مؤسسات لتصميم وتخصيص وتحسين تطبيقات أودو عبر جميع الوظائف ومستويات التعقيد. سواء أردت تصميم نموذج بيانات متين، تكوين قواعد تحقق، أو بناء موديلات مخصصة — فريقنا يقدم خبرة وظيفية وتقنية في كل مشروع.
إذا كانت لديك أسئلة حول الحقول المطلوبة أو أي جانب آخر من إعداد أودو، يسعدنا مساعدتك. تواصل معنا ولنناقش ما ترغب في بنائه.