وحدات أودو المخصصة وسير العمل التجارية

ماذا ستخرج به من هذا المقال؟

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

أُضيف حقل «تاريخ التسليم المطلوب» إلى أمر البيع، مع رسالة تلقائية للعميل عند التأخير. يبدو الأمر بسيطاً حتى تجد نفسك تفتح ملفات أودو الأساسية وتعدّل الأسطر التي أنشأتها ميزة «المبيعات» نفسها. يعمل كل شيء اليوم، لكن الترقية القادمة ستحوّل هذه النقطة من تحديث بسيط إلى مشروع إعادة بناء كامل. أودو مرن، لكن لكل شركة سير عمل خاص بها، والوحدات المخصصة (Custom Modules) هي الطريقة الصحيحة لتطويع أودو لعملياتك دون كسر التحديثات المستقبلية. في هذا المقال تبني وحدة مخصصة كاملة بالوراثة: حقولاً، وطرق عرض، ومنطق عمل، وترحيلاً بين الإصدارات، مع مثال تطبيقي كامل ومعايير جودة تحمي استثمارك المؤسسي.

لماذا التخصيص العشوائي خطير؟

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

• تعديل نواة أودو مباشرة يمنع الترقية لاحقاً: أي تحديث قادم يستبدل الملفات التي عدّلتها أو يتعارض معها، فتُفقد تعديلاتك أو يتعطل النظام عند أول ترقية.


• كود مبعثر في عدة أماكن يصعب صيانته: إصلاح أو إضافة واحدة تتطلب البحث في عشرات الملفات، وكل بحث يزيد احتمال كسر ما يعمل بلا انتباه.


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


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


• غياب شبكة أمان اختبارية: تعديل لا يُختبر تلقائياً قد يكسر عملية نقدية مثل المحاسبة أو المخزون دون أن يلاحظ أحد حتى يطرق العميل الباب بشكوى.

المفاهيم الأساسية

• الوحدة (Module): حزمة بايثون مستقلة تحتوي نماذج وحقولاً وطرق عرض ومنطقاً وبيانات وتعريباً، تُثبَّت وتُحدَّث ككيان واحد، وهي وحدة العزل والترقية في أودو.


• الوراثة (Inheritance): توسيع نموذج موجود دون تعديله عبر _inherit، فيبقى كود النواة نظيفاً وتستطيع وحدات عدة الإضافة بأمان دون اصطدام.


• سير العمل (Workflow): انتقال الحالة عبر مراحل (مسودة ← مؤكدة ← مكتملة) بقيود تحدد متى يُسمح بكل انتقال ومَن يملك تنفيذه.


• طرق العرض (Views): ملفات XML وصفية تحدد شكل النموذج (نموذج تعديل، قائمة، بحث) للمستخدم، وتُورَّث تماماً كما تُورَّث النماذج.


• البيانات (Data): سجلات تُحقن عبر ملفات XML أو CSV مثل حالات القوائم ومجموعات المستخدمين وقوالب البريد، وتُعرَّف بمعرفات XML مستقرة وثابتة.


• الترحيل (Migration): برامج بايثون أو SQL تُنفَّذ عند تحديث الوحدة بين الإصدارات لتحويل البيانات أو البنية بهدوء دون تدخل يدوي.

رحلة بناء وحدة

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

خطوة بخطوة: بناء وحدة مخصصة

الخطوة 1: أنشئ بنية الوحدة

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

custom_sale/

  __init__.py

  __manifest__.py

  models/__init__.py

  models/sale_order.py

  views/sale_order_views.xml

  security/ir.model.access.csv

النتيجة: وحدة معزولة لا تلمس نواة أودو، وتُحمَّل وتُوقَف ككيان واحد.

الخطوة 2: عرّف الملف التعريفي

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

{

    "name": "Custom Sale",

    "version": "18.0.1.0.0",

    "depends": ["sale"],

    "data": [

        "security/ir.model.access.csv",

        "views/sale_order_views.xml",

    ],

    "installable": True,

    "application": False,

}

النتيجة: أودو يعرف الوحدة واعتماديتها على المبيعات ويحمّل ملفاتها بالترتيب الصحيح.

الخطوة 3: وسّع النموذج بالوراثة

الوراثة في أودو تعني تعريف فئة بايثون ترث النموذج الأصلي: تضيف الحقول والقيود كما لو كانت جزءاً منه دون لمس ملفاته. الحقول الجديدة تُعرَّف كخصائص fields.* وتصبح متاحة فوراً في تقارير المحاسبة وواجهات البحث والتصدير. للحقول التي يُعبّئها نظام خارجي استخدم بادئة x_ المعتمدة مجتمعياً، حتى لا يتعارض اسمك مع أسماء النواة في الترقيات أو مع وحدات أخرى في نفس المؤسسة.

from odoo import models, fields



class SaleOrder(models.Model):

    _inherit = "sale.order"



    delivery_notes = fields.Text("Delivery notes", help="Free-form delivery instructions")

    required_by = fields.Date(string="Required by", tracking=True)

النتيجة: الحقل يُضاف للنموذج، وتتراكم التخصيصات من وحدات متعددة بأمان، وتبقى الترقية نظيفة.

الخطوة 4: أضف طريقة عرض

الحقل بلا طريقة عرض شيء للماكينة لا يراه أحد. وراثة نموذج الواجهة عبر inherit_id مع xpath تُدرج حقولك في موضع محدد. احذر من الاستقرار: إن تغيّر مكان العقدة المرجعية في إصدار أودو قادم انكسرت الطريقة وتوقفت الواجهة، لذا استهدف عناصر مستقرة معروفة مثل حقل note. ولا تنسَ ملف ir.model.access.csv: النموذج الجديد معدوم الصلاحيات افتراضياً، وبدونه تُرفض القراءة أو الكتابة برسائل «لا قيمة وصول» محيّرة.

<record id="view_order_form_custom" model="ir.ui.view">

  <field name="name">sale.order.form.custom</field>

  <field name="model">sale.order</field>

  <field name="inherit_id" ref="sale.view_order_form"/>

  <field name="arch" type="xml">

    <xpath expr="//field[@name='note']" position="after">

      <field name="required_by"/>

      <field name="delivery_notes"/>

    </xpath>

  </field>

</record>

النتيجة: يظهر الحقلان للمستخدم في النموذج المعتاد دون لمس النموذج الأصلي، ويُعفى المهندس من صيانة نسخة واجهة موازية.

الخطوة 5: أضف منطقاً على الحفظ

المنطق فوق النموذج يُكتب بتجاوز الدوال الحالية: نفّذ ما تريد ثم استدعِ super() لضمان استمرار سلوك النواة كما هو. انتبه لترتيب المعالجة: التعديل قبل super() يضمن رؤية القيمة الجديدة في الخطوات اللاحقة التي تشغّلها النواة. تعامل مع self كمجموعة سجلات عبر حلقة، لأن أودو يستدعي الدالة على دفعات وقد تتغاضى عن قيمة واحدة فيتكدس سير العمل بطلبات بلا نص.

def action_confirm(self):

    for rec in self:

        if not rec.delivery_notes:

            rec.delivery_notes = "تسليم قياسي خلال 48 ساعة"

    return super().action_confirm()

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

الخطوة 6: خطّط للترحيل

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

custom_sale/

  migrations/

    18.0.1.1.0/pre.py

    18.0.1.1.0/post.py

النتيجة: الترقية لا تكسر التخصيص، وبياناتك تنتقل تلقائياً بين الإصدارات دون نسخ يدوي.

مثال عملي كامل: وحدة موافقة على الخصم

شركة مبيعات اشترطت ألا يتجاوز خصم المندوب 10% دون موافقة مدير المبيعات، وكانت النتيجة أزمة أسبوعية: طلبات تتأكد بخصم أعلى ومدير يكتشف الأمر متأخراً بعد إرسالها للعميل. بنى الفريق وحدة ورثت نموذج المبيعات، أضافت حقل خصم محسوباً وحالة «بانتظار موافقة»، وتجاوزت action_confirm لتمنع التأكيد حين يتجاوز الخصم السقف ما لم تكن موافقة مسجلة. بقيت الوحدة معزولة تماماً، فحين انتقلت الشركة من أودو 17 إلى 18، لم تُجرَ إلا خطوات الترحيل المرتبطة بالوحدة نفسها وظل سقف الخصم محمياً من اليوم الأول.

مقارنة: وراثة مقابل تعديل النواة

أخطاء شائعة

قائمة تحقق سريعة

• الوحدة معزولة في مجلد مستقل ببنية واضحة للملفات


• الملف التعريفي يعلن الاعتماديات كاملة ونسخة قابلة للترقيع


• التوسيع عبر _inherit لا عبر تعديل النواة


• طرق العرض ترث النماذج الأصلية عبر inherit_id


• الصلاحيات محددة لكل مجموعة مستخدمين في ir.model.access.csv


• المنطق التجاري في بايثون مفصول عن الواجهة


• خطة ترحيل جاهزة لكل إصدار عبر migrations


• اختبارات للمنطق الحرج قبل التثبيت في الإنتاج


• توثيق قصير لسير العمل وقرارات التصميم

الأسئلة الشائعة

هل أحتاج برمجة لبناء وحدة؟

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

كيف أحمي ترقيات أودو؟

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

كم وحدة مخصصة كثيرة جداً؟

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

ماذا أفعل إن غيّرت النواة هيكل حقل أعتمد عليه في إصدار جديد؟

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

الخلاصة

الخطوة التالية

بعد بناء الوحدات، تعلّم ربط أودو بأنظمة خارجية في «دمج أودو مع المنصات الخارجية».

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["واجهة المستخدم"]

    B["وحدة Odoo"]

    C["قواعد الصلاحيات وORM"]

    D["PostgreSQL"]

    E["تقارير ومخرجات"]

    A --> B

    B --> C

    C --> D

    D --> E