أخطاء تثبيت تابي وتمارا في أودو وطريقة قراءة السجل
ليش ما تطلع إضافة تابي وتمارا في التطبيقات أو يوقف تثبيتها على أودو 14 إلى 19، وش يختلف بين الإصدارات، وكيف تقرأ سجل الـAPI لما تفشل دفعة.
لما ترفض إضافة دفع تتثبت، أول شي يجي في بالك إن العيب فيها. لكن أغلب الأعطال اللي نشوفها تصير قبل ما أودو يقرأ سطر واحد من كودها: المجلد أعمق من مكانه بمستوى، أو النسخة مكتوبة لإصدار ثاني، أو أودو كان مشغول بمهمة مجدولة وقت ضغطت تثبيت. هالدليل يمشي معك على الأعطال بنفس الترتيب اللي بتواجهها فيه، وبعدها يشرح لك كيف تقرأ سجل الـAPI اللي تحفظه وحدة تابي وتمارا لأودو لكل طلب ترسله. وكل اللي فيه مأخوذ من كود الإضافة نفسه، فرع فرع، ومن كود أودو الرسمي.
فحصين يختصرون عليك نص المشاكل
وين قاعدة بياناتك. أودو أونلاين ما يقبل أي إضافة خارجية، لا منا ولا من غيرنا. إذا متجرك هناك، ما في حل تقني يطلع لك زر التثبيت. الخيارات وطريقة نقل القاعدة مشروحة في مقارنة كوميونيتي وإنتربرايز والاستضافة.
أي فرع عندك. لكل إصدار من أودو فرع خاص، من 14.0 إلى 19.0، ولازم يطابق الإصدار الرئيسي لسيرفرك بالضبط. ما في فرع 20.0 للحين، ونسخة 19.0 ما تنفع هناك لأنها تعبّي حقل الحالة (State) في مزود الدفع، وأودو 20 شال هالحقل.
وشي تقدر ترتاح منه: ما تحتاج تثبت أي مكتبة بايثون. الإضافة ما تستخدم من خارج أودو إلا requests، وأودو أصلاً يحتاجها.
الإضافة ما تطلع في التطبيقات
أي وحدة من هذي لحالها تكفي تخفيها:
- المجلد أعمق بمستوى. أودو يدوّر على الملف
payment_tabby_tamara/__manifest__.pyمباشرة داخل كل مجلد في مسار الإضافات (addons path). إذا المجلد اللي نسخته فيه مجلد ثاني بنفس الاسم، أودو ما راح يشوفها أبد. وإذا المسار نفسه غلط، يطلع في سجل السيرفرaddons path does not existوقت التشغيل. - ما أعدت تشغيل أودو. مسار الإضافات ينقرأ مرة وحدة وقت التشغيل.
- قائمة التطبيقات قديمة. فعّل وضع المطور واضغط «تحديث قائمة التطبيقات» من قائمة التطبيقات. هالخيار ما يبان إلا مع وضع المطور.
- الفلتر مخبّيها. هذي تطيّح حتى أصحاب الخبرة. شاشة التطبيقات تفتح وعليها فلتر «التطبيقات» اللي يعرض بس الوحدات المصنفة كتطبيق، ومزود الدفع مو تطبيق. شيل الفلتر وبعدين ابحث عن تابي.
وعلى Odoo.sh لازم يكون المجلد مرفوع في نفس الفرع اللي تشوفه. اللي على فرع التجربة (staging) ما يوصل الإنتاج إلا بعد الدمج.
تأكد من الفرع قبل التثبيت
مع وضع المطور افتح بطاقة الإضافة في التطبيقات، وشوف رقم الإصدار في تبويب «معلومات». أودو يحط رقم إصداره قدّام أي رقم ما يبدأ فيه، فالنسخة الصحيحة على أودو 18 تطلع بشكل 18.0.2.1.0، بينما نسخة 17.0 لو انحطت على أودو 18 تطلع 18.0.17.0.2.1.0. رقمين إصدار ورا بعض معناها الفرع غلط، بدّله قبل لا تثبت.
التثبيت يوقف برسالة خطأ
«يقوم أودو حالياً بمعالجة إجراء مجدول»
وبالإنجليزي تبدأ بـ «Odoo is currently processing a scheduled action». أودو يرفض أي تثبيت أو ترقية أو إزالة وقت ما تكون في مهمة مجدولة شغالة. الإضافة ما فيها شي، انتظر دقيقة وجرب مرة ثانية.
ParseError أو «Invalid field» على ملف داخل الإضافة
اقرأ الخطأ من تحت لفوق. إذا الملف المذكور داخل payment_tabby_tamara، فالسبب في الغالب نسخة لإصدار ثاني، لأن الشاشات والحقول وحزم الملفات تتغير بين إصدارات أودو. تأكد من الرقم مثل ما شرحنا وبدّل المجلد.
المتصفح يعلق والصفحة تنتهي مهلتها
الإضافة تعتمد على الموقع والمتجر الإلكتروني ونقاط البيع، فإذا قاعدتك ما فيها هالتطبيقات تنزل كلها مع نفس الضغطة. والسيرفر اللي شغال بنظام العمّال (workers) يعطي كل طلب من المتصفح 120 ثانية افتراضياً وبعدها يقفل العامل. لو طلع لك بعدها في سجل السيرفر Some modules have inconsistent states، فالتثبيت ما كمل.
الأضمن تثبت من سطر الأوامر لأن هالحد ما ينطبق هناك. أوقف الخدمة، شغّل الأمر بملف الإعدادات حقك، ورجّع الخدمة:
odoo-bin -c your.conf -d your_database -i payment_tabby_tamara --stop-after-init
الخيارات -i و-u وحدود الوقت موثقة في مرجع سطر الأوامر من أودو. وبأي طريقة، جرّب التثبيت على نسخة من قاعدتك أول، لأن نزول الموقع ونقاط البيع على قاعدة شغالة يغيّر القوائم عند كل الموظفين.
تثبتت، بس في شي ناقص
تابي وتمارا مو موجودين في الكاشير
وقت التثبيت تحاول الإضافة تسوي طريقتين دفع لنقاط البيع، تابي وتمارا، على أول دفتر بنكي في الشركة. القاعدة الجديدة اللي ما تجهزت فيها المحاسبة ما فيها دفتر، فتتجاوز الخطوة وتكتب في سجل السيرفر: deferred creating the BNPL POS methods (no journal/account yet); upgrading the module later will create them.
جهّز المحاسبة ورقِّ الإضافة مرة وحدة وتطلع الطريقتين، أو سوّها بيدك من نقاط البيع، الإعدادات، طرق الدفع، مع علامة Tabby BNPL أو Tamara BNPL. الإنشاء التلقائي للشركة الحالية بس، فلو عندك أكثر من شركة سوّ الباقي يدوي. ومن أودو 15، الطريقة اللي عليها العلامة بدون دفتر ترفض تنحفظ برسالة تبدأ بـ «A BNPL payment method must have a Journal». أي دفتر تختار؟ الجواب في دليل محاسبة دفعات التقسيط، والكاشير نفسه له دليل التقسيط في نقاط البيع.
المزودين موجودين والمتجر ما يعرضهم
هذا مقصود. المزودين ينشأون معطّلين، ومن أودو 16 غير منشورين بعد. جهّزهم وانشرهم مثل ما في خطوات ربط تابي مع أودو، ولو واحد ظل مختفي، فحص المزود اللي ما يطلع في صفحة الدفع يمر على كل فلتر.
وش يختلف بين الإصدارات
| أودو | اسم الشاشة | سجل الـAPI | دفعات الكاشير تمر على |
|---|---|---|---|
| 14.0 | Payment Acquirers | ما فيه، سجل السيرفر بس | حساب الذمم المدينة |
| 15.0 | Payment Acquirers | موجود | دفتر |
| 16.0 إلى 19.0 | Payment Providers | موجود | دفتر |
| 20.0 | ما في فرع للحين |
في كوميونيتي تلقى هالشاشات تحت الفوترة، وفي إنتربرايز تحت المحاسبة.
الترقية
نسخة جديدة على نفس إصدار أودو. بدّل المجلد، أعد تشغيل أودو، وبعدها رقِّ الإضافة من بطاقتها أو بالخيار -u payment_tabby_tamara. إعادة التشغيل تحمّل كود بايثون، والترقية تحدّث الشاشات والبيانات، ولو نسيت وحدة منهم تشتغل بنص من كل نسخة. مفاتيحك ما تنمسح، لأن سجلات المزودين تنكتب مرة وحدة وقت التثبيت والترقية ما تلمسها. وبعدها حدّث صفحة أي كاشير مفتوح.
على فرع الإنتاج في Odoo.sh، أي رفع يعيد تشغيل السيرفر بالكود الجديد، لكن الترقية التلقائية في Odoo.sh ما تصير إلا إذا زاد رقم الإصدار في ملف الـmanifest. ولو فشلت، يرجع للنسخة اللي قبلها.
إصدار جديد من أودو. الفرع ينتقل مع القاعدة، وباقي المشروع في مقارنة كوميونيتي وإنتربرايز. على النسخة المرقّاة تأكد إن المفاتيح موجودة، اضغط «اختبار الاتصال»، وادفع طلب تجريبي لين آخره.
لا تزيل الإضافة عشان تبدأ من الصفر
الإزالة تحذف جداول الإضافة نفسها: سجل الـAPI، وسجلات دفع المحل اللي فيها أرقام الدفعات اللي تحتاجها استرجاعات الكاشير. وحقول المفاتيح تروح معها. أما طريقتين الدفع اللي انسوت وقت التثبيت فهي سجلات عادية، تبقى كطرق دفع عادية، يعني الكاشير يقدر يختار «Tabby» ويسجل دفعة ما أكدتها أي بوابة. الترقية تصلح اللي الناس يتوقعون الإزالة تصلحه، وبدون هالضرر.
كيف تقرأ سجل الـAPI
من أودو 15 تلقى السجل في الفوترة أو المحاسبة، تحت الإعدادات، جنب مزودي الدفع. اسمه بالعربي «سجل واجهة برمجة تطبيقات تابي/تمارا» وبالإنجليزي Tabby/Tamara API Log، وما يفتحه إلا مدراء النظام ومدراء المحاسبة. كل سطر فيه طلب واحد أرسله أودو: التاريخ والمزود والطريقة ونقطة النهاية وحالة HTTP وخانة الخطأ. السطر الأحمر معناه رمز 400 أو أعلى، أو network-error لما البوابة ما تنوصل أصلاً. افتح أي سطر وتلقى تبويبين: الطلب والرد.
| نقطة النهاية | وش هي |
|---|---|
تابي POST /api/v2/checkout |
إنشاء صفحة الدفع |
تابي GET /api/v2/payments/{id} |
قراءة الحالة بعد رجوع العميل أو وصول إشعار |
تابي POST .../captures و.../refunds |
التحصيل والاسترجاع |
تابي GET /api/v2/payments?limit=1 |
اختبار الاتصال |
تمارا POST /checkout |
إنشاء صفحة الدفع |
تمارا GET /orders/{id} |
قراءة الحالة |
تمارا POST /orders/{id}/authorise و/payments/capture |
التفويض والتحصيل |
تمارا POST /payments/simplified-refund/{id} |
الاسترجاع |
تمارا GET /orders/00000000-... |
اختبار الاتصال |
أنماط تختصر عليك
- عملية تابي سليمة ثلاث سطور بدون خطأ: إنشاء، قراءة، تحصيل.
- 404 أحمر على سطر الأصفار معناه نجاح. اختبار اتصال تمارا يطلب طلب مستحيل يكون موجود، فالرمز الصحيح يرجع «غير موجود». الفشل الحقيقي هو 401 على نفس السطر.
- 401 في أي مكان معناه مفتاح غلط أو مفتاح من البيئة الثانية. ولو مفاتيح تابي صادرة في السعودية، راجع رابط الـAPI في المزود.
network-errorمعناه السيرفر ما وصل للبوابة: جدار ناري أو بروكسي أو DNS. المفاتيح ما انفحصت أصلاً.- 400 على إنشاء الدفع سببه الحقيقي مكتوب في تبويب الرد، بينما العميل شاف رسالة مختصرة. رسائل تمارا مشروحة وحدة وحدة في دليل ربط تمارا مع أودو.
- إنشاء سليم وبعده ولا شي، مع إن العميل رجع، يعني المشكلة في أودو مو في البوابة. دوّر في سجل السيرفر على
Tabby/Tamara: error finalising.
ولو تبي تتبع طلب واحد، أضف فلتر مخصص على «الطلب» يحتوي مرجع الطلب، خذ رقم الدفعة أو الطلب من تبويب الرد، وابحث فيه في نقاط النهاية.
وش ما تلقاه في السجل
- الطلبات الجاية لك. الإشعارات ورجوع العميل تنكتب في سجل السيرفر، أما الفحص اللي يسويه أودو بعدها فتلقاه هنا.
- دفعات الكاشير. كل وحدة حالتها وخطأها في سجلها تحت نقاط البيع، Tabby Payments.
- عنوان السيرفر. ينحفظ المسار بس، فالسطر ما يفرّق بين التجربة والإنتاج. في تابي بادئة المفتاح هي اللي تحدد، وفي تمارا حالة المزود.
- مفاتيحك. ترويسة التفويض ما تنحفظ، والحقول اللي اسمها فيه key أو token أو secret تنخفى. لكن أسماء العملاء وجوالاتهم وعناوينهم تنحفظ، فخل الصلاحية ضيقة. والنص يوقف عند 6,000 حرف، وما في شي يمسح السطور القديمة تلقائياً.
أودو 14 ما فيه شاشة سجل، وسجل السيرفر فيه يحفظ عنوان كل طلب وحالته بدون المحتوى. ولما يصير السجل نظيف، خطوتك الجاية خطة الاختبار قبل الإطلاق.
أسئلة متكررة
نسخت الإضافة على السيرفر، ليش ما تطلع في التطبيقات؟
غالباً واحد من أربعة: المجلد أعمق بمستوى من مكانه، أو ما أعدت تشغيل أودو، أو ما حدّثت قائمة التطبيقات من وضع المطور، أو فلتر «التطبيقات» شغال. هالفلتر يعرض التطبيقات بس، ومزود الدفع مو تطبيق، فشيله قبل ما تبحث.
أقدر أثبت نسخة 19.0 على أودو 20؟
لا. كل فرع مكتوب لإصدار واحد من أودو، ونسخة 19.0 تعبّي حقل الحالة في مزود الدفع، وأودو 20 شال هالحقل. وما في فرع 20.0 وقت كتابة هالمقال، فالمتجر اللي يستقبل تابي أو تمارا عن طريق الإضافة يبقى على 19 أو أقدم حالياً.
لو رقّيت الإضافة، بتنمسح مفاتيح تابي وتمارا؟
لا. سجلات المزودين تنكتب مرة وحدة وقت التثبيت والترقية ما تكتب فوقها، فالمفاتيح والإعدادات تبقى. الإزالة شي ثاني: تحذف حقول المفاتيح وسجل الـAPI وسجلات الدفع في المحل.
اختبار الاتصال مع تمارا نجح، ليش في سطر أحمر في السجل؟
الاختبار يطلب من تمارا طلب مستحيل يكون موجود. لو الرمز صحيح يرجع 404 يعني «غير موجود»، والإضافة تعتبره نجاح، بينما السجل يلوّن بالأحمر أي رمز من 400 وفوق. لو شفت 401 على نفس السطر، هنا المشكلة الحقيقية.
وين ألقى أخطاء الدفع في نقاط البيع؟
مو في سجل الـAPI. كل دفعة في الكاشير لها سجلها الخاص تحت نقاط البيع، Tabby Payments، وفيه حالتها وآخر خطأ صار. أما مشاكل الموقع والبوابة والفواتير فتروح لسجل الـAPI.