Odoo Studio أم الشيفرة المخصّصة؟ كيف أقرّر ما الذي أبنيه

يبدأ الأمر دائماً بطلب صغير. يسألني العميل إن كان بالإمكان إضافة حقل لعمولة الوسيط، أو إظهار اسم السائق في سند التسليم، أو إخفاء ثلاثة حقول لا يملؤها أحد في فريق المبيعات. وجوابي الصريح في أغلب الأحيان هو «نعم»، فـ Odoo تستطيع ذلك. غير أن السؤال الذي أجيب عنه فعلاً وراء كل طلب من هذه الطلبات ليس: هل هذا ممكن؟ بل: هل أفتح Studio أم أفتح محرّر الشيفرة؟ فهذا الاختيار، متى تكرّر دون عناية كافية، هو ما يحوّل نظام Odoo النظيف إلى نظام لا يرغب أحد في المساس به بعد إصدارين من الآن.

ما يجيده Studio فعلاً

تصف Odoo أداة Studio في وثائقها بأنها صندوق أدوات لتخصيص Odoo دون الحاجة إلى معرفة بالبرمجة، وهي كذلك فعلاً في شريحة لا يُستهان بها مما يطلبه العملاء. وثمة أمر ينبغي معرفته قبل أي شيء آخر: Studio لا يأتي إلا مع نسخة Enterprise، ويُفعِّل تثبيته على خطة Standard في Odoo Online عرضاً تلقائياً للانتقال إلى خطة Custom، وهي الفئة نفسها التي تتيح تعدّد الشركات وواجهة برمجة التطبيقات (API) الخارجية. وإن لم تكن قد حسمت بعد النسخة التي ستعمل عليها، فإن هذا القرار تتجاوز آثاره الوصول إلى Studio بكثير.

الحقول هي أوضح الأمثلة. فـ Studio يتيح لك إضافة حقل غير موجود بعد، أو إدراج حقل قائم في أي عرض. ولأن Odoo توثّق 15 نوعاً أساسياً من الحقول، فإن حقول Studio تُحفظ أعمدةً حقيقية في قاعدة بياناتك، لا طبقةً موازية مُركَّبة فوق النظام. وتنطبق الفكرة نفسها على العروض (views): فالنموذج (form) والكانبان (kanban) والقائمة (list) والتقويم (calendar) والجدول المحوري (pivot) والرسم البياني (graph) ونحو ستة أنواع أخرى هي، بتعبير Odoo، مجرّد طرق مختلفة لعرض البيانات نفسها، ويتيح لك Studio إعادة ترتيب ما يعرضه كل منها دون المساس بشيفرة XML.

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

أين يتوقف Studio

تظهر الحدود الحقيقية سريعاً ما إن تتجاوز ما يُروَّج له من أن Studio لا يتطلب برمجة. فنوعان من إجراءات Studio نفسه، وهما Execute Code وSend Webhook Notification، هما بحد ذاتهما ضرب من البرمجة، ولذلك فعبارة «دون كتابة شيفرة» أقرب إلى طيف متدرّج منها إلى وعد قاطع: فمتى احتاجت قاعدة أتمتة إلى مقطع شيفرة أو إلى حمولة بيانات خطّاف ويب (Webhook)، أصبح الأمر بحاجة فعلاً إلى من يستطيع كتابة تلك الشيفرة واختبارها، سواء تمّ ذلك داخل واجهة Studio أم خارجها.

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

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

مخطط القرار الذي أعتمده

بدلاً من إعادة فتح هذا الجدل في كل مشروع، أمرّر كل طلب على الأسئلة الثلاثة نفسها وبالترتيب نفسه. قد يبدو ذلك جامداً، لكنه يوفّر علينا من الخلافات أكثر مما يثير: فمعظم طلبات «التخصيص» يتبيّن أنها إمّا شيء يؤديه التطبيق القياسي أصلاً، أو شيء يتولاه Studio بسلاسة. أما ما يحتاج فعلاً إلى شيفرة مخصّصة فهو فئة أصغر مما يتوقعه معظم الناس عند بدء المشروع؛ وحين أحصيتُ ما يُبنى فعلاً في صورة وحدات مخصّصة عبر 10 عمليات تطبيق في الإمارات، ظلّت المحاسبة تتقدّم على كل تطبيق آخر بفارق كبير.

التكاليف الخفية بعيدة المدى

لا يقتصر أثر المكان الذي يُنفَّذ فيه التغيير على عمل هذا الأسبوع، بل يمتد إلى ما ستبدو عليه السنوات الثلاث التالية من عمر نظام Odoo لديك.

هشاشة التخصيصات عند الترقية

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

من يستطيع صيانته

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

قابلية الاختبار وطريقة تطبيق التغييرات

يمكن حفظ الوحدات المخصّصة في نظام للتحكم في الإصدارات (version control)، ومراجعتها، واختبارها على نسخة مرحلية (Staging) قبل أن يمسّ أحد بيئة الإنتاج، وهذا هو الانضباط نفسه الذي تتوقعه من أي تغيير برمجي. أما تغييرات Studio فتُجرى مباشرةً على قاعدة بيانات الإنتاج عبر محرّر مرئي، وهذا ما يجعلها سريعة، لكنه يعني كذلك أنه لا يوجد فيها ما يعادل طلب الدمج (pull request) مضمّناً في الأداة نفسها. وأعالج ذلك بالاحتفاظ بسجل مكتوب لكل تغيير في Studio خارج Odoo، ليبقى لدينا على الأقل أثر موثّق لما تغيّر ولسبب تغييره.

النظام القياسي أولاً

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

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

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

قراءات ذات صلة

مزيد من الأدلّة بقلمي: Odoo Community مقابل Enterprise: كيف تختار، وهو قرار النسخة الذي يحدّد أصلاً ما إذا كان Studio متاحاً لك؛ وما الذي يحدّد فعلاً تكلفة تطبيق Odoo في الإمارات، وفيه ترى أين يظهر قرار المفاضلة بين Studio والوحدة المخصّصة في ميزانيتك؛ وكيف تختار شريك تطبيق Odoo في الإمارات، وفيه السؤال الذي أرى أن على كل مشترٍ أن يطرحه بشأن ما لا ينبغي تخصيصه.