اختبار قبول Odoo 19 نجح كمدير وفشل للمستخدم الحقيقي

العرض ينجح بصلاحيات كاملة. سجّل دخول الدور الفعلي فتختفي المجلدات والقوالب والورديات والقوائم. إليك كيف تختبر الصلاحيات قبل التشغيل.

يتناول هذا المقال بنداً واحداً من قائمتي 11 مشكلة في Odoo 19 من مشاريع حقيقية. النظام لم يكن معطلاً. الاختبار أُجري ببيانات الدخول الخطأ.

ما رأيناه

سار العرض بشكل جيد. وسار اختبار القبول أيضاً بشكل جيد. كل خطوة في سيناريو الاختبار نجحت: المستندات موجودة، وقالب التوقيع موجود، والورديات موجودة، والقائمة تُفتح.

ثم سجّل المستخدم الحقيقي الدخول في أسبوع التشغيل، واختفى نصف ذلك.

رأى مجلدات مستندات أقل بكثير. لا قوالب توقيع. لا ورديات مخططة — الورديات موجودة لكنها ما زالت مسودة، وهذا الدور لا يستطيع رؤيتها. إحدى القوائم ظهرت في التنقل لكنها لم تُفتح عند النقر عليها.

لم يُحذف شيء. ولم يتغير شيء منذ الاختبار. الفرق الوحيد كان بيانات الدخول. الاختبار أُجري كمدير. أما المستخدم الحقيقي فكان له دور عادي بمجموعات وقواعد سجلات ناقصة.

لماذا يخفي المدير المشكلة

المدير يرى كل شيء. لا تنقصه أي مجموعة صلاحيات، ولا ترشّح أي قاعدة سجلات أي شيء، ولا تخفي أي حالة مسودة أي سجل.

وهذا ما يجعل المدير أسوأ دخول لاختبار القبول. عندما يشغّل المدير السيناريو، يجيب الاختبار عن سؤال مختلف عن السؤال الذي تحتاجه: "هل هذه الميزة موجودة في النظام؟" بدل "هل يستطيع هذا الشخص أداء عمله في النظام؟"

معظم مشكلات الصلاحيات التي أراها تقع في أربع مجموعات:

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

كل واحدة من هذه تنجح عندما ينقّر المدير. وكل واحدة تفشل في أول يوم استخدام حقيقي.

لماذا يوجع هذا

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

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

كيف تتحقق من ذلك قبل التشغيل

شغّل كل سيناريو قبول ببيانات دخول الشخص الذي سيؤدي العمل، لا المدير. سيناريو واحد، ودخول حقيقي واحد، من البداية إلى النهاية.

1. أنشئ دخول الاختبار بالمجموعات نفسها التي سيملكها الدور الحقيقي تماماً. دون صلاحيات إضافية "لأجل الاختبار".
2. سجّل الدخول بذلك المستخدم في نافذة متصفح خاصة، حتى لا تتسرب أي جلسة مدير.
3. نفّذ السيناريو كاملاً: افتح كل قائمة، واعرض المجلدات، وافتح قالب التوقيع، وتحقق من الورديات المخططة، وقدّم طلباً واحداً من البداية إلى النهاية.
4. حيث تبدو القائمة قصيرة، سجّل الدخول كمدير في نافذة ثانية وقارن العدد. إذا رأى المدير عشرة مجلدات ورأى المستخدم ثلاثة، فقد وجدت قاعدة أو مجموعة تحتاج إلى إصلاح.
5. اختبر المنع أيضاً: جرّب شيئاً لا ينبغي للدور أن يستطيع فعله، وتأكد أنه ممنوع.

فحصان يتجاوزهما الناس غالباً:

• السجلات المسودة. إذا كانت العملية تستخدم المسودات — ورديات أو مستندات أو قوالب — تحقق منها كالدور وهي ما زالت مسودة، لا بعد الاعتماد فقط.
• القوائم التي تظهر ولا تُفتح. انقر كل قائمة يراها الدور. القائمة الظاهرة التي تعطي خطأ عند الفتح علامة كلاسيكية على مجموعة ناقصة.

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

ما نفعله الآن

بعد أن واجهنا هذا في مشروع حقيقي، غيّرنا قاعدة الاختبار:

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

ماذا تفعل إذا كان نظامك يعمل بالفعل

إذا كان فريقك يعمل على Odoo 19 ويشكو بعض المستخدمين من مجلدات أو قوالب أو ورديات مفقودة:

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

تحتاج إلى مراجعة ثانية؟

إذا رأى بعض المستخدمين أقل مما ينبغي في Odoo 19، أو نجح قبولك وفشل التشغيل، تواصل معي.