الحقل الإلزامي في أودو: كيفية عمله واستخدامه بفعالية

مقدمة

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

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

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

ما هو الحقل المطلوب في أودو

في أودو، خاصية required هي قيد على مستوى الحقل يمنع حفظ السجل ما لم يحتوي الحقل على قيمة. وهي تنطبق على جميع أنواع حقول أودو تقريبًا: حقول النصوص، حقول الأرقام، حقول الاختيار، حقول many2one، التواريخ، والمزيد.

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

كيف تظهر في الواجهة

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

هذا السلوك متسق عبر واجهة الويب. يرى المستخدمون ردود فعل فورية وواضحة، مما يقلل من فرصة تقديم سجلات غير مكتملة.

المطلوب الثابت مقابل المطلوب الديناميكي

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

تستخدم كلا الطريقتين بانتظام في تطوير أودو. يعتمد الاختيار على منطق عملك.

كيف يعمل الحقل

فهم كيفية عمل خاصية required على المستوى الفني يساعدك على تطبيقها بشكل صحيح وتصحيح المشكلات عندما تظهر.

فرض مستوى التطبيق

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

لا يتم إضافة قيد NOT NULL إلى عمود PostgreSQL الأساسي بشكل افتراضي عند تعيين required=True على حقل. يحدث التحقق في بايثون، داخل طبقة ORM الخاصة بأودو.

في الممارسة العملية، يعني ذلك أن البيانات المدخلة مباشرة في قاعدة البيانات (متجاوزةً Odoo) لن يتم التقاطها بواسطة القيد المطلوب. تفاعل دائمًا مع حقول قاعدة بيانات Odoo الخاصة بك من خلال ORM أو API للاستفادة من هذه الحماية.

ماذا يحدث عندما يتم انتهاك القيد

عندما يحاول المستخدم حفظ نموذج مع حقل مطلوب ترك فارغًا، يحدث شيئان:

• يتحول الحقل إلى اللون الأحمر في الواجهة، وتظهر Odoo رسالة تحقق
• يتم حظر عملية الحفظ حتى يتم ملء الحقل

إذا قمت بتفعيل التحقق برمجيًا (على سبيل المثال، عبر XML-RPC API أو إجراء خادم)، ترفع Odoo ValidationError مع رسالة تشير إلى أي حقل مطلوب مفقود.

المطلوب الديناميكي باستخدام المجالات

في إطار عمل Odoo، يمكن جعل خاصية required شرطية باستخدام تعبيرات على مستوى العرض. في Odoo 16 وما قبله، يتم ذلك باستخدام خاصية attrs في XML العرض:

<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />

في Odoo 17 وما بعده، تم تبسيط الصياغة باستخدام تعبير required مباشر على علامة الحقل في العرض:

<field name="x_delivery_date" required="order_type == 'delivery'" />

تعيش هذه القواعد الشرطية في طبقة العرض، وليس في طبقة النموذج. هذه تمييز مهم: required=True على مستوى النموذج يفرض دائمًا القيد، بينما تنطبق التعبيرات على مستوى العرض فقط في سياقات واجهة معينة.

التفاعل مع ORM و API

في ORM الخاص بـ Odoo، عندما تستدعي create() أو write() على نموذج، يتحقق ORM من جميع الحقول التي تم تعيينها إلى required=True قبل تنفيذ عملية قاعدة البيانات. إذا كان هناك حقل مطلوب مفقود أو تم تعيينه إلى False، فإن Odoo يرفع ValidationError.

ينطبق هذا أيضًا عند إنشاء سجلات عبر واجهة برمجة التطبيقات XML-RPC. يجب تقديم أي حقل مُعَلم كمطلوب في تعريف النموذج في القاموس البياني المرسل إلى طريقة create، وإلا ستفشل المكالمة مع ظهور خطأ.

حالات الاستخدام التجارية

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

1. إدارة علاقات العملاء: حقل شريحة العميل مطلوب على العملاء المحتملين

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

من خلال وضع علامة على حقل اختيار "شريحة العميل" المخصص كحقل مطلوب في نموذج عميل CRM، يضمن الفريق دائمًا التقاط البيانات عند نقطة الإدخال. لا شريحة، لا حفظ.

2. المبيعات: حقل عنوان التسليم مطلوب على الطلبات

بالنسبة للشركات التي تشحن سلعًا مادية، فإن عنوان التسليم أمر حاسم. في بعض تكوينات Odoo، لا يكون حقل عنوان التسليم مطلوبًا بشكل افتراضي، مما يعني أنه يمكن تأكيد الطلبات بدون واحد.

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

3. المخزون: رقم الدفعة أو الرقم التسلسلي مطلوب عند الاستلام

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

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

4. المحاسبة: مركز التكلفة مطلوب في فواتير الموردين

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

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

5. الموارد البشرية: نوع العقد مطلوب قبل التوظيف

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

إنشاء أو تخصيص الحقل

هناك طريقتان رئيسيتان لتحديد حقل كحقل مطلوب في Odoo: استخدام Odoo Studio لنهج بدون كود، أو كتابة كود بايثون للحصول على تحكم كامل. كلاهما صالح حسب السياق الخاص بك.

استخدام Odoo Studio

Odoo Studio هو الأداة المدمجة بدون كود التي تتيح لك تكوين الحقول دون أي تطوير. عند فتح Studio واختيار حقل في نموذج، سترى مفتاح "مطلوب" في لوحة خصائص الحقل على اليمين.

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

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

النهج الفني: حقول بايثون

في وحدة أودو مخصصة، فإن إعلان حقل مطلوب بسيط مثل إضافة required=True إلى تعريف الحقل. هذه هي النمط القياسي في تطوير حقول بايثون في أودو:

from odoo import fields, models

class SaleOrder(models.Model):
    _inherit = 'sale.order'

    x_customer_segment = fields.Selection(
        selection=[
            ('smb', 'SMB'),
            ('enterprise', 'Enterprise'),
            ('public', 'Public Sector'),
        ],
        string='Customer Segment',
        required=True,
    )

    x_cost_center_id = fields.Many2one(
        comodel_name='account.analytic.account',
        string='Cost Center',
        required=True,
    )

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

المطلوب الديناميكي في XML العرض

عندما يجب أن ينطبق القيد المطلوب فقط تحت ظروف معينة، أضفه على مستوى العرض بدلاً من مستوى النموذج. في أودو 16:

<field name="x_cost_center_id"
       attrs="{'required': [('order_type', '=', 'invoiced')]}" />

في أودو 17:

<field name="x_cost_center_id"
       required="order_type == 'invoiced'" />

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

إنشاء حقول مطلوبة عبر API

إذا كنت تستخدم واجهة XML-RPC لإنشاء الحقول (كما تم تغطيته في مقالات أخرى في مجموعة بيانات أودو و API)، يمكنك تعيين required عند استدعاء create على ir.model.fields. هذا جزء من دليل مطوري أودو القياسي للتخصيص البرمجي:

models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
    'ir.model.fields', 'create',
    [{
        'name': 'x_customer_segment',
        'field_description': 'Customer Segment',
        'model_id': model_id,
        'ttype': 'selection',
        'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
        'required': True,
        'state': 'manual',
    }]
)

هذا ينشئ الحقل ويطبق القيد المطلوب في خطوة واحدة، وهو مفيد في سير العمل الآلي لنشر سيناريوهات إنشاء الحقول في أودو.

أفضل الممارسات

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

1. اجعل الحقول مطلوبة فقط عندما تكون مطلوبة حقًا

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

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

2. استخدم التحقق القائم على المرحلة بدلاً من المطلوب دائمًا

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

هذا النمط أكثر مرونة وسهولة في الاستخدام من جعل كل حقل مطلوبًا منذ اليوم الأول.

3. اقترن الحقول المطلوبة بالقيم الافتراضية حيثما كان ذلك منطقيًا

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

4. فضل الحقول المطلوبة على مستوى النموذج للبيانات الحرجة

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

5. التواصل مع المستخدمين حول الحقول المطلوبة

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

6. اختبار البيانات الفارغة والجزئية

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

المزالق الشائعة

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

فخ 1: جعل حقل مطلوبًا في نموذج يحتوي بالفعل على سجلات

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

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

فخ 2: الخلط بين الحقول المطلوبة على مستوى العرض ومستوى النموذج

تعيين حقل كمطلوب في عرض (سواء من خلال الاستوديو أو XML العرض) لا يفرض القيد على مستوى النموذج. سيتم تجاوز السجل الذي تم إنشاؤه عبر واجهة برمجة التطبيقات، أو عرض مختلف، أو استيراد القيود المطلوبة على مستوى العرض تمامًا.

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

فخ 3: الحقول المطلوبة في الإجراءات الآلية أو المجدولة

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

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

الفخ 4: استيراد بيانات تفتقر إلى الحقول المطلوبة

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

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

الفخ 5: استخدام الحقول المطلوبة بدلاً من قيد Python للتحقق المعقد

تتحقق خاصية required فقط من أن الحقل ليس فارغًا. إنها لا تتحقق من المحتوى أو العلاقة بين الحقول. للتحقق الأكثر تعقيدًا (على سبيل المثال، التأكد من أن التاريخ في المستقبل، أو أن حقلين متسقين)، استخدم زينة @api.constrains في Python بدلاً من ذلك.

محاولة ترميز منطق الأعمال في الحقول المطلوبة فقط تؤدي إلى تكوينات غير مرنة يصعب صيانتها.

الخاتمة

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

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

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

هل تحتاج إلى مساعدة في تنفيذ أودو الخاص بك؟

في Dasolo، نساعد الشركات على تنفيذ وتخصيص وتحسين Odoo عبر جميع وظائف الأعمال ومستويات التعقيد. سواء كنت بحاجة إلى مساعدة في تصميم نموذج بيانات قوي، أو تكوين قواعد التحقق، أو بناء وحدات مخصصة، فإن فريقنا يجلب كل من الخبرة التقنية والوظيفية إلى كل مشروع.

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