---
title: "ترقية أودو مع الإضافات المخصصة: ليش هي الي تأخر كل شي وكيف تخلي الترقية الجاية أرخص"
description: "ترقية أودو لنسخة جديدة تتعطل غالبًا عند الإضافات المخصصة، مو عند تطبيقات أودو. وش ينكسر بين النسخ، وخطوات الترقية، وكيف تكتب إضافة ترقيتها الجاية أرخص."
lang: ar-SA
canonical: https://www.kerneltics.com/blog/odoo-upgrade-custom-modules
source: https://www.kerneltics.com/blog/odoo-upgrade-custom-modules
alternate_en: https://www.kerneltics.com/en/blog/odoo-upgrade-custom-modules
type: article
published: 2026-10-15T06:15:26.244Z
updated: 2026-10-15T06:15:26.266Z
author: "kerneltics"
tags: ["Odoo", "أودو", "ترقية أودو", "إضافات أودو", "تطوير موديولات", "ERP"]
---

# ترقية أودو مع الإضافات المخصصة: ليش هي الي تأخر كل شي وكيف تخلي الترقية الجاية أرخص

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

قررتوا ترقية أودو لنسخة جديدة. طلبتوا نسخة تجريبية، وأودو رقّى المبيعات والمخزون والمحاسبة بدون مشكلة. وبعدها وقف كل شي عند سطر واحد: «الموديول الفلاني ما يتثبّت».

هذا هو الوضع الطبيعي، مو الاستثناء. [توثيق أودو للترقية](https://www.odoo.com/documentation/19.0/administration/upgrade.html) يقولها صريحة: قاعدة البيانات الي فيها إضافات مخصصة ما تترقّى لين تجهز نسخة من هالإضافات للنسخة الجديدة. يعني تطبيقات أودو القياسية تترقّى بأدوات أودو، والي يحدد متى تخلص الترقية هو كودك أنت.

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

## متى تصير ترقية أودو إجبارية؟

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

- **Odoo Online:** الترقية من نسخة رئيسية (مثل 17.0 أو 18.0) إجبارية كل سنتين، ومن النسخ الفرعية (مثل 17.2) بعد أسابيع من نزول الي بعدها. وإذا ما سويت شي قبل الموعد، تشتغل لحالها.
- **Odoo.sh:** بعد سنوات الدعم الثلاث، عندك سنتين زيادة تكمّل فيها الترقية.
- **سيرفر خاص (On-premise):** تقدر تبقى على نسختك على طول، بس أودو ما ينصح، ويقول إن كل ما صغرت الفجوة بين النسختين سهلت الترقية.

والترقية ما ترجعك لنسخة أقدم، وما تنقلك من Community إلى Enterprise، وما تغيّر نوع الاستضافة. وعلى Odoo Online أصلًا ما فيه إضافات بايثون مخصصة (شرحنا ليش في [تشتري إضافة من متجر أودو ولا تبنيها؟](https://www.kerneltics.com/blog/odoo-apps-store-vs-custom))، فالكلام الجاي كله لمن هو على Odoo.sh أو سيرفر خاص.

## مين يرقّي وش؟

أودو يعتبر «مخصص» أي موديول يوسّع كود أودو القياسي وما انبنى بـ Studio. وهذا التقسيم من [اتفاقية مستوى الخدمة في صفحة الترقية](https://www.odoo.com/documentation/19.0/administration/upgrade.html#service-level-agreement-sla):

| القطعة | مين يرقّيها |
|---|---|
| تطبيقات أودو القياسية | أودو، ضمن اشتراك Enterprise |
| تعديلات Studio | أودو، بشرط Studio لسا مثبّت واشتراكه شغال |
| إضافة مخصصة عليها عقد صيانة تخصيصات مع أودو | أودو |
| إضافة كتبها فريقك أو أي طرف ثالث، حتى لو كان شريك أودو | الي يصونها، مو أودو |
| إضافة من متجر أودو | ناشرها، وتشتريها للنسخة الجديدة من جديد |
| تنظيف البيانات القديمة وتدريب الموظفين | أنت |

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

وإذا أنت على Community، فالترقية المجانية من أودو جزء من اشتراك Enterprise. الطريق المعروف هنا مشروع [OpenUpgrade](https://github.com/OCA/OpenUpgrade) من مجتمع أودو (OCA)، وفيه سكربتات ترحيل لوحدات أودو نفسها. وإضافاتك المخصصة تبقى عليك في الحالتين.

## وش الي ينكسر في الإضافة بين نسخة ونسخة؟

أودو يغيّر كثير بين النسخ، وأغلب التغييرات التقنية مكتوبة في [سجل تغييرات الـ ORM](https://www.odoo.com/documentation/19.0/developer/reference/backend/orm/changelog.html) وملاحظات الإصدار. هذي أمثلة حقيقية من هناك ومن توثيق الترقية:

### الشاشات (Views)

- أودو 17 شال `attrs` و`states` من تعريف الشاشات. أي إضافة تخفي حقل أو تقفله بـ `attrs` لازم تنكتب من جديد.
- أودو 18 غيّر اسم شاشات القوائم من `tree` إلى `list`.
- الـ xpath الي يأشّر على مكان في شاشة أودو، لو المكان انتقل أو انحذف، تفشل الوراثة. وأثناء الترقية، الشاشة الي تسبب مشكلة تتعطّل، وتلقاها في تقرير الترقية (Upgrade report).
- تحديثات OWL وطريقة تعريف ملفات الواجهة (assets)، فأي إضافة تلمس الكاشير أو شاشات JavaScript تحتاج شغل حقيقي مع كل نسخة.

### دوال الـ ORM

- `name_get()` صارت قديمة من 16.4، والبديل حقل `display_name`.
- خاصية `group_operator` في الحقول تغيّر اسمها إلى `aggregator` في 17.2.
- `read_group` صارت قديمة في 18.2، والبديل `_read_group` داخل السيرفر و`formatted_read_group` للواجهة.
- أودو 19 خلّى `record._cr` و`record._context` و`record._uid` قديمة.

ونقطة تفوت كثير: الأرقام مثل 16.4 و17.2 و18.2 نسخ فرعية تنزل على Odoo Online أول، وتغييراتها توصل الباقين مع النسخة الرئيسية الجاية. يعني تغيير 17.2 تشوفه أنت في 18، وتغيير 18.2 تشوفه في 19.

### النماذج والبيانات

- نماذج تندمج أو تنحذف. مثال أودو نفسه: `sale.subscription` اندمج في `sale.order` في أودو 16، والحقول المخصصة الي كانت عليه ما تنتقل تلقائيًا.
- حقل تعتمد عليه إضافتك ينشال. وهذا بالضبط الي صار مع إضافتنا، تحت.
- السجلات المعلّمة `noupdate` ما تتحدّث مع ترقية الموديول. لو عدّلت في الإضافة قالب إيميل أو بيانات أساسية من هالنوع، ما راح توصل للقاعدة المرقّاة بدون سكربت.

## خطوات ترقية أودو مع الإضافات المخصصة

هذا الترتيب الي يوصي فيه [دليل أودو لترقية قاعدة فيها تخصيصات](https://www.odoo.com/documentation/19.0/developer/howtos/upgrade_custom_db.html)، ومعه الي نضيفه من الشغل.

### 1. وقّف التطوير وراجع وش صار جاهز

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

من الشغل: سوّ جدول فيه كل إضافة، وش تسوي، ومين يستخدمها، وهل لسا تحتاجونها.

### 2. اطلب نسخة تجريبية مرقّاة

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

واعرف إن النسخة التجريبية «محيّدة»: المهام المجدولة موقفة، والإيميل الصادر معطّل، وبوابات الدفع وشركات الشحن راجعة لوضع الاختبار، ومزامنة البنك موقفة. وعلى السيرفر الخاص، الملفات المرفقة (filestore) ما تجي مع القاعدة المرقّاة، لازم تدمجها مع ملفاتك بنفسك.

وعندنا في السعودية شي ما هو في هالقائمة: الفوترة الإلكترونية مع هيئة الزكاة. قبل ما تعتمد أي فاتورة على النسخة التجريبية، تأكد على أي وضع ربطها (محاكاة ولا إنتاج)، لأن الفاتورة الي توصل بوابة الإنتاج تنحسب. شرحنا الوضعين في [الفوترة الإلكترونية في أودو](https://www.kerneltics.com/blog/zatca-einvoicing-odoo).

### 3. ركّب كل إضافة على قاعدة فاضية من النسخة الجديدة

قبل البيانات الحقيقية، ثبّت إضافاتك وحدة وحدة على قاعدة فاضية من النسخة الهدف، وصلّح كل خطأ وتحذير. هنا تطلع الاعتماديات الغلط، و`attrs`، والحقول والشاشات الي تغيّر اسمها، والـ xpath الي ضاع مكانه.

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

### 4. شغّلها على القاعدة المرقّاة

الحين تجيب البيانات. أي شي غيّرت اسمه في كودك (نموذج، حقل، معرّف XML) لازم ينتقل بسكربت ترحيل، وإلا تضيع بياناته. وراجع الشاشات المعطّلة في تقرير الترقية، والسجلات `noupdate` الي تحتاج تحديث.

على Odoo.sh، فرع staging المرقّى يشتغل على وضع «تحديث مع كل commit»: كل ما رفعت تعديل ترجع النسخة المرقّاة من أولها وتتحدّث إضافاتك وتشتغل سكربتاتها، والسجل في `~/logs/upgrade.log`. وعلى السيرفر الخاص تحدّثها بنفسك بالخيار `-u`.

### 5. اختبر عمليتك كاملة، وبعدها سوّ بروفة

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

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

### 6. يوم الإنتاج

القاعدة تكون موقفة طول الترقية، فاختار وقت يكون الشغل فيه أقل. وأي شي ينكتب بعد ما ترفع القاعدة للترقية ما يكون في النسخة المرقّاة، فلا أحد يشتغل عليها وقتها. على Odoo.sh لو فشلت الترقية ترجّعها المنصة لحالها، ولو نجحت تحفظ نسخة احتياطية من القاعدة قبل الترقية. وعلى السيرفر الخاص، النسخة الاحتياطية مسؤوليتك.

## سكربتات الترحيل: الأداة الي تحفظ بياناتك

[سكربت الترحيل](https://www.odoo.com/documentation/19.0/developer/reference/upgrades/upgrade_scripts.html) (upgrade script) ملف بايثون فيه دالة اسمها `migrate(cr, version)`، يشغّلها أودو وقت تحديث الموديول. ومكانه داخل الإضافة نفسها:

```
my_module/
  upgrades/
    18.0.1.1/
      pre-rename_fields.py
      post-move_data.py
      end-cleanup.py
```

- اسم المجلد `upgrades`، أو `migrations` القديم. وتحته رقم النسخة الكامل: نسخة أودو ثم نسخة الإضافة.
- السكربت **ما يشتغل إلا إذا رقم الإضافة زاد**. نسيت ترفع `version` في `__manifest__.py`؟ السكربت ما يشتغل.
- ثلاث مراحل: `pre` قبل ما يتحمّل الموديول، و`post` بعد ما يتحمّل هو واعتمادياته، و`end` بعد ما تخلص كل الموديولات. وداخل كل مرحلة تشتغل الملفات بترتيب أسمائها.
- مكتبة أودو المساعدة (upgrade utils) فيها دوال للحالات الشائعة: `rename_field` و`rename_model` و`rename_xmlid` عشان تغيير الاسم ما يمسح البيانات، و`recompute_fields` لو تغيّرت طريقة الحساب، و`remove_module` لإضافة ما عاد تحتاجونها.

## مثال من شغلنا: إضافة وحدة على ست نسخ من أودو

[تابي وتمارا لأودو](https://tabby.kerneltics.com) إضافة بنيناها في كيرنلتكس وننشرها في متجر أودو، تربط الدفع بالتقسيط مع المتجر الإلكتروني ونقاط البيع والفواتير. (الإضافة من تطويرنا، وما هي تابعة لتابي ولا تمارا.) نذكرها لأنها تعيش نفس المشكلة الي يتكلم عنها هالمقال: لها **فرع لكل نسخة من 14.0 إلى 19.0**، على Community وEnterprise، والفرع لازم يطابق نسخة السيرفر بالضبط. وكل الي تحت مكتوب في دليل التثبيت على موقعها.

**نفس الإضافة، بس مو نفس الكود.** بين فرع وفرع تتغير أشياء أساسية:

- الشاشة الي تضبط فيها البوابة اسمها Payment Acquirers في أودو 14 و15، وPayment Providers من 16 لين 19.
- شاشة سجل طلبات الـ API موجودة من أودو 15. في 14 ما فيه إلا سجل السيرفر.
- دفعات التقسيط في الكاشير تمر على حساب الذمم المدينة في 14، وعلى دفتر يومية من 15.
- من أودو 16، البوابات تنشأ غير منشورة في المتجر لين تنشرها أنت.

**حقل واحد يكفي يوقف كل شي.** فرع 19.0 يعبّي حقل الحالة (State) في سجل بوابة الدفع، وأودو 20 شال هالحقل. فنسخة 19.0 ما تشتغل على 20، ووقت كتابة دليلها ما كان فيه فرع 20.0. التغيير الي يكسر الإضافة ما يحتاج إعادة تصميم، يكفي حقل ينشال.

**كيف تعرف إن الفرع غلط قبل ما تثبّت.** أودو يحط رقم نسخته قدّام رقم الإضافة لو ما بدأ فيه. فالنسخة الصحيحة على أودو 18 تطلع `18.0.2.1.0`، أما فرع 17.0 لو انحط على 18 فيطلع `18.0.17.0.2.1.0`. رقمين نسخة ورا بعض معناها الفرع مو لنسختك.

**أقل اعتماديات، أقل كسر.** الإضافة ما تستخدم من خارج أودو إلا مكتبة `requests`، وأودو نفسه يحتاجها. يعني ما فيه مكتبة بايثون زيادة لازم تتثبّت على السيرفر الجديد.

**التحديث داخل نفس النسخة.** بدّل المجلد، أعد تشغيل أودو، ورقِّ الإضافة (`-u payment_tabby_tamara`). إعادة التشغيل تحمّل كود البايثون، والترقية تحدّث الشاشات والبيانات، ولو نسيت وحدة منهم تشتغل بنص من كل نسخة. ومفاتيح الربط تبقى، لأن سجلات البوابات تنكتب مرة وحدة وقت التثبيت.

**ولا تزيلها عشان تبدأ من جديد.** الإزالة تحذف جداول الإضافة: سجل الـ API، وسجلات دفعات الكاشير الي تحتاجها المرتجعات، وحقول المفاتيح.

## كيف تكتب إضافة ترقيتها الجاية أرخص

الترقية تنكسب أو تنخسر وقت كتابة الإضافة، مو وقت الترقية:

1. **وراثة بس.** `_inherit` ووراثة الشاشات، وصفر تعديل على ملفات أودو. فصّلناها في [تطوير إضافات أودو حسب شغلك](https://www.kerneltics.com/blog/odoo-custom-addons-development).
2. **xpath على شي ثابت.** `//field[@name='partner_id']` يعيش أطول من `//group[2]/field[3]`، لأن ترتيب العناصر في شاشات أودو يتغير أكثر من أسماء الحقول.
3. **كل إضافة تسوي شي واحد.** خمس إضافات صغيرة تترقّى وحدة وحدة، وتقدر تحذف منها الي صار قياسي. الإضافة العملاقة تترقّى كلها أو ما تترقّى.
4. **ارفع رقم النسخة مع كل تغيير في البيانات، والسكربت معه في نفس الـ commit.** لا تأجل سكربتات الترحيل لين الترقية الكبيرة.
5. **اختبارات آلية للعمليات المهمة.** أودو نفسه ينصح فيها لأنها توفّر جولات الاختبار. الاختبار الي ينجح على 17 ويفشل على 18 يدلك على المشكلة قبل الموظف.
6. **فرع لكل نسخة من أودو** في مستودع الكود، مثل ما نسوي في إضافة تابي وتمارا. الإصلاح ينتقل للفروع الثانية عن قصد، مو بالصدفة.
7. **اكتب ليش كل إضافة موجودة.** الخطوة الأولى في أي ترقية سؤال «لسا نحتاجها؟»، وجوابه أسهل لو مكتوب.

## أسئلة سريعة

### نقدر ننقل أودو من 14 إلى 18 مرة وحدة؟

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

### كم تاخذ ترقية أودو؟

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

### نقدر نرجع للنسخة القديمة لو ما عجبتنا؟

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

### اشترينا إضافة من المتجر وما لها نسخة للإصدار الجديد. وش نسوي؟

تنتظر الناشر، أو مطور يرقّيها لاستخدامكم لو الرخصة تسمح، أو تستبدلها بشي قياسي أو بإضافة ثانية. وتذكّر إن كل نسخة تنباع لحالها. فصّلنا هالقرار في [تشتري إضافة من متجر أودو ولا تبنيها؟](https://www.kerneltics.com/blog/odoo-apps-store-vs-custom).

### الترقية بتحل مشاكل أودو الي عندنا؟

لا. أودو يقول إن تنظيف البيانات والإعدادات القديمة مو جزء من الترقية، والفوضى تنتقل معك للنسخة الجديدة. لو المشكلة في طريقة التطبيق نفسها، اقرأ [ليش مشاريع أودو تتعثر](https://www.kerneltics.com/blog/odoo-implementation-goes-wrong) قبل ما تشوف الترقية كحل.

## كيف نشتغل عليها

في كيرنلتكس نبدأ بجرد كل إضافة عندكم: وش تسوي، ووش صار منها قياسي في النسخة الجديدة. بعدها نطلب نسخة تجريبية مرقّاة، وننقل كل إضافة على قاعدة فاضية من النسخة الهدف مع اختبارات وسكربتات ترحيل، ثم على نسخة من بياناتكم. وفريقكم يجرّب عملياته الحقيقية قبل بروفة يوم الإنتاج. وتستلمون الكود في فرع لكل نسخة، مثل ما نصون [تابي وتمارا لأودو](https://tabby.kerneltics.com).

شوف [صفحة أودو](https://www.kerneltics.com/odoo) و[أودو مع الفوترة الإلكترونية](https://www.kerneltics.com/solutions/odoo-zatca)، أو [احجز استشارة](https://www.kerneltics.com/book) وأرسل لنا نسختكم الحالية وقائمة إضافاتكم.