مشروع التحول وإعادة هيكلة نظام مدارس الكودة

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

وضع المعاينة
حجم المنظومة التشغيلية
+33,000
طالب وطالبة في +40 مدرسة (3 دول)
نسبة تغطية الأساسيات (Must-Have)
27%
من أصل 30 بنداً حرجاً في استمارة التقييم
إجمالي المهام المطلوبة
18
تم تحويل كافة الملاحظات والتقارير لمهام
المهام المعتمدة من العميل
0 / 18
بانتظار الاعتماد: 18
المهام المنجزة تقنياً
0 / 18
تُحدّث تلقائياً من لوحة المهام
تقييم الجاهزية قبل بداية SoftMagic (من استمارة 33)
مقارنة البيئتين الحاليتين على السيرفر
البند النسخة التشغيلية (Odoo 17) النسخة التجريبية (Odoo 19)
الحالة شغالة فعلياً (Docker) ترحيل غير مكتمل (Systemd)
الموديولات المدرسية 15 موديول (تشمل الامتحانات، الحضور، الجدول، المكتبة، السكن، الرواتب، التقارير) 9 موديولات فقط (فقدت الامتحانات والحضور والجدول والمكتبة والرواتب والتقارير الديناميكية!)
نسبة الجاهزية الميدانية 27% أساسي / 7% مهم جداً (تداخل بين بيانات المدارس الـ 40) إضافات متفرقة (تحديد سقف التسجيل + تعديلات Studio عشوائية)
الخلاصة الاعتماد على الكود الحالي كما هو يحمل مخاطر عالية؛ الحل السليم هو تأسيس معمارية نظيفة للعزل والرسوم والترحيل.
الهدف من هذه الصفحة: توثيق ما تم استلامه من إدارة مدارس الكودة قبل استلام شركة SoftMagic للمشروع، لإثبات الحالة المبدئية (Baseline) وتوضيح الفجوات الفعلية بشفافية كاملة للطرفين.
أولاً: الملخص التنفيذي للوضع المستلم

استُلمت منظومة مدارس الكودة في مرحلة انتقالية بعد توقف العمل مع المنفذ السابق، وهي تخدم حالياً أكثر من 33,000 طالب وطالبة عبر +40 مدرسة في السودان ومصر والسعودية بنظام الشركات المتعددة (Multi-Company). أظهر الفحص الفني للوثائق والكود المصدري أن النظام مبني على موديولات SerpentCS المفتوحة المصدر مع تعديلات متفرقة أدت إلى فجوات تشغيلية جوهرية في العزل بين المدارس والرسوم والتقارير.

ثانياً: أبرز المشاكل التقنية الموثقة قبل SoftMagic
  • اختلاط بيانات المدارس (Multi-Company Leak): المراحل الدراسية، الفصول، هيكل الرسوم، أولياء الأمور، وتطبيق النقل تظهر مشتركة بين المدارس بدلاً من عزل كل مدرسة.
  • أخطاء إنشاء السجلات والصلاحيات: ظهور خطأ "لا توجد سجلات" عند إضافة طالب في بعض المدارس، ومنع وصول (Access Error) عند إضافة طالب لخط نقل.
  • خلل مسار التسجيل والتحصيل: السماح بانتقال الطالب إلى مرحلة "استلام الرسوم" دون التحقق من السداد، وعدم وجود آلية واضحة لإدارة الأقساط المتعددة أو استرجاع ملف الطالب الملغى.
  • انفصال الامتحانات عن السجل الأكاديمي: وحدة الامتحانات غير متكاملة مع ملف الطالب؛ ولا يوجد ترحيل تلقائي للناجحين للصف التالي.
  • قصور الطباعة والتقارير: تنسيق الفواتير غير متناسق، زر فواتير النقل لا يعمل، وغياب تقارير أعمار الديون والأقساط المتبقية.
  • إيضاح التراخيص: تم تأكيد أن النظام هو Odoo Community مفتوح المصدر ولا يتطلب رسوم اشتراك سنوي للمستخدمين.
ثالثاً: نتائج استمارة التقييم (Odoo Evaluation Form-33)
مستوى الأولوية نسبة التغطية المستلمة عدد البنود التقييم
الضروريات (Must-have) 27% 30 بنداً فجوة حرجة
مهم جداً (Very important) 7% 20 بنداً غير متاح تقريباً
اختياري (Optional) 17% 8 بنود تغطية جزئية
فجوات بنسبة 0% (غير موجودة عملياً): الترحيل السنوي للطلاب، الحضور والغياب، الامتحانات والنتائج، والإشعارات التلقائية لأولياء الأمور.
إضافة مهمة جديدة إلى خطة التنفيذ
التوصية الهندسية الحاسمة: لا ننصح بالبناء التراكمي الأعمى فوق الكود الحالي كما هو (لا في Odoo 17 ولا في Odoo 19)، لأن الأساس الحالي يعاني من خلل هيكلي في الـ Multi-Company قد يتسبب في كارثة مالية أو تسرب بيانات مع 33,000+ طالب و 40+ مدرسة في 3 دول.
لماذا البناء على الكود الحالي مخاطرة؟ (أدلة من الكود)
  • ثغرة الـ Record Rules: في school_fees/security/company_rules.xml، القاعدة تسمح برؤية السجلات التي company_id = False؛ أي سجل يُنشأ بدون شركة يظهر لجميع المدارس الأربعين!
  • نماذج بلا عزل أصلاً: المراحل الدراسية (standard.standard)، الشعب، أولياء الأمور، والمدارس السابقة تفتقر إلى company_id الصارم وcheck_company=True.
  • ترقيع متراكم (Technical Debt): وجود دوال معالجة يدوية مثل action_recompute_company_id_for_all_students وتعديلات Studio بأسماء عشوائية (c17942792077, cap_51891721058069) في Odoo 19 تجعل الصيانة والتحديث كابوساً.
  • Odoo 19 غير مكتملة: تم حذف موديولات أساسية في الترقية (الامتحانات، الحضور، الجدول، التقارير الديناميكية).
المسار الموصى به (الأساس النظيف الآمن)
استراتيجية "Clean Core + Controlled Migration":
  1. الاحتفاظ بنسخة Odoo 17 كنسخة تشغيلية مؤقتة مع تركيب موديول الـ Diagnostic API لفحص جودة البيانات الحية دون إيقاف المدارس.
  2. بناء نواة نظيفة (Clean Core) على إصدار مستقر (Odoo 17 LTS أو Odoo 18):
    • إبقاء البيانات التاريخية سليمة عبر فصل طبقة التخصيصات في موديول مستقل alkoda_core بدلاً من تعديل كود SerpentCS مباشرة.
    • تطبيق عزل صارم للشركات المتعددة (company_id إجباري + check_company=True + تقسيم دول/إدارات/مدارس).
    • بناء محرك أقساط وفوترة يعتمد على فواتير أودو القياسية (account.move) لضمان التوافق مع ZATCA (السعودية) وETA (مصر).
  3. خطة ترحيل بيانات منظمة: تنظيف بيانات الـ 33,000 طالب من النسخة التشغيلية قبل نقلها للنواة الجديدة.
هذه الأسئلة الموضوعية مصممة لرفعها لإدارة مدارس الكودة لحسم القرارات المعمارية والمالية قبل كتابة أول سطر كود. يمكنك تدوين إجاباتهم هنا وحفظها.
موديول الفحص والتقييم التشخيصي (alkoda_diagnostic_api) لنسخة Odoo 17

تم تجهيز موديول Odoo 17 للقراءة فقط (Read-Only) ومؤمّن بمفتاح X-Alkoda-Token في المسار d:\sedor\alkoda_diagnostic_api، لتركيبه في النسخة التشغيلية وفحص بيانات الـ 33,000+ طالب بدقة:

نقطة الاتصال (Endpoint) ماذا تفحص في النسخة التشغيلية؟
GET /api/alkoda/diag/overview إحصائيات الطلاب النشطين والملغيين، عدد المدارس، الشركات، الفواتير، الموديولات المنصّبة، وتوزيع الطلاب لكل شركة.
GET /api/alkoda/diag/multi_company_audit كشف السجلات اليتيمة بدون company_id (في الطلاب، المراحل، الفصول، الرسوم، النقل، أولياء الأمور) وقياس حجم تسرب البيانات بين الفروع.
GET /api/alkoda/diag/fees_audit فحص هياكل الرسوم، إيصالات الطلاب (student.payslip)، الفواتير المربوطة، وحالات عدم تطابق الشركة بين الطالب وفاتورته.
GET /api/alkoda/diag/permissions_audit جرد قواعد الوصول (ir.rule) ومجموعات الصلاحيات لمعرفة أسباب أخطاء "لا توجد سجلات" و"منع الوصول" في النقل.