سؤال عملي قبل أي إعداد: موظفان في المبيعات، هل يرى كل واحد منهما كل العملاء؟
الجواب يُحدَّد بالدور والحاجة والإجراء، لا بقاعدة واحدة للجميع. في مثال توضيحي: يرى المندوب عملاءه، ويرى مدير المبيعات عملاء فريقه، ويقرأ المحاسب الفواتير دون تعديل أوامر البيع. أما حق الموافقة المالية فمنفصل: من ينشئ عرض السعر لا يعتمد بالضرورة الخصم أو الدفع.
النتيجة التي نريدها: مدير يعرف من يرى ماذا ولماذا، ومالية تتتبع الموافقات بلا التباس، وفريق يعمل يومه ويعرف متى ينجز عمله ومتى يطلب صلاحية إضافية. وهذا يتغير بتغير حجم الفريق وطريقة البيع، لذلك نكتب القرار مرة واحدة ونختبره.
في تودو اوبس - ToDoOps نحدد مع أصحاب العمليات الأدوار ونطاق السجلات، ثم نهيئ الإعدادات وندرب الفريق ونختبرها بحسابات تمثل عمله. يتيح اودو حقوقًا على أنواع السجلات وقواعد تحدد السجلات التي يصل إليها المستخدم؛ سياسة الموافقة قرار آخر يُضبط ضمن سير العمل 1.
صلاحيات اودو بين المبيعات والمالية: ما النتيجة المطلوبة؟
مالك شركة يسأل: «هل يستطيع مندوب المبيعات رؤية فواتير الشركة كلها؟» ومدير المالية يسأل بالمقابل: «هل أستطيع مراجعة الفواتير دون أن يرى كل موظف بيانات الشركة؟» الجوابان مختلفان، ولا يصحّان إلا إذا اتفقتم أولًا على الدور والعملية. الهدف المعقول: المبيعات تتابع فرصها، والمالية تراجع الفواتير، دون كشف كل بيانات الشركة لكل شخص. تعاملوا مع هذه الأدوار كإعداد محدد تختبرونه، لا كافتراض.
حقوق الوصول وقواعد السجلات والموافقة في اودو
1. حقوق النموذج (Model access). تحدد عمليات CRUD على نوع السجل، وتُمنح عبر المجموعات. حقوق المجموعات تتراكم (additive)، فمن ينتمي لمجموعتين يحصل على مجموع حقوقهما 1.
2. قواعد السجلات (Record Rules). تُطبَّق على السجلات بعد حقوق النموذج. وإذا مُنحت حقوق العملية على النموذج ولم تنطبق قاعدة سجلات على المستخدم والعملية والنموذج، فالأصل هو السماح ضمن تلك الحقوق، وفق ما يوثقه المرجع 1. لذلك لا تفترض أن غياب القاعدة يعني التقييد.
3. الموافقة. إذن التعديل على سجل ليس سياسة موافقة مالية. من يستطيع تعديل الفاتورة ليس بالضرورة من يعتمدها. الموافقة تحتاج سير عمل واضحًا واختبارًا بحسابات أصحاب الأدوار أنفسهم.
ملاحظات تطبيقية:
- الأدوار قد تختلف بحسب التطبيق، وبعضها يغطي «مستنداته فقط» أو «كل المستندات» (Own Documents / All Documents) في تطبيقات معينة لا في كلها.
- مستخدم البوابة (Portal) الخارجي يختلف عن الموظف الداخلي. ويتحدد الوصول وفق نوع الحساب والصلاحيات التي راجعتموها.
- إخفاء قائمة (Menu) ليس برهانًا على صلاحية البيانات؛ قد يبقى الوصول ممكنًا من مسار آخر.
مصفوفة أدوار تتفقون عليها
هذه مصفوفة هدف مشروع وليست افتراضات جاهزة في المنتج. الأدوار افتراضية، والنموذج المختار «أوامر البيع» لتوضيح الفكرة:
على الجوال، اسحب الجدول أفقياً إذا لم تظهر جميع الأعمدة.
| الدور | قراءة | إنشاء | تعديل | حذف |
|---|---|---|---|---|
| المبيعات | سجلاته فقط | نعم | سجلاته قبل التأكيد | لا |
| المستودع | المؤكدة لأغراض التسليم | لا | لا | لا |
| المالية | نعم | لا | لا | لا |
ثلاثة أدوار × أربع عمليات = 12 خلية اختبار. لكل خلية تلائم نموذج الاختبار نكتب حالة سماح وحالة منع، فيصبح المقترح 24 حالة اختبار. هذا العدد مقترح للاختبار، وليس 24 ضابطًا أمنيًا ولا متطلبًا من الهيئة الوطنية للأمن السيبراني. وإن لم يلائم النموذج أحد الاختبارين في خلية ما، فسجّلوا ذلك ولا تصطنعوه.
يمكن تقدير تكلفة التطبيق ووقته ووفوراته افتراضيًا فقط عبر الحاسبات، وهي لتقدير نطاق تطبيق النظام، بينما المصفوفة هنا تحدد ما ستختبره في العمل.
قواعد الاختبار
- استخدموا بيانات تجريبية، ولا تطلبوا صلاحيات تصدير كاملة، ولا تضعوا بيانات شخصية أو سجلات حقيقية في الاختبار.
- اختبروا بحسابات أصحاب الأدوار أنفسهم، لا بحساب المدير وحده.
- افعلوا ذلك في نسخة معزولة وبمسؤول معتمد؛ فالضبط الخاطئ قد يقفل الإدارة عن الوصول.
مرجع حوكمة: ضوابط الأمن السيبراني الأساسية
تقدم الهيئة الوطنية للأمن السيبراني في وثيقة ضوابط الأمن السيبراني الأساسية (ECC 2-2024) مبادئ مفيدة لحوكمة الوصول، في الصفحات المطبوعة 19–20 (وهي 22–23 في ملف PDF): الحاجة إلى المعرفة والاستخدام، وأقل صلاحية وفصل المهام (2.2.3.3)، وإدارة الوصول المميز (2.2.3.4)، والمراجعة الدورية للهويات وحقوق الوصول (2.2.3.5) 2. نستفيد منها مرجعًا لتنظيم القرار، ونربطها بسياسة الصلاحيات والمتطلبات المعتمدة لدى منشأتكم.
ترجمتها العملية بسيطة: امنح كل دور ما يحتاجه لعمله، وافصل من ينشئ عمن يعتمد، وضيّق من يملك صلاحيات إدارية، وراجع القائمة بانتظام.
الخروج الوظيفي والنقل الداخلي
عند خروج موظف أو انتقاله من المبيعات إلى المالية مثلًا، راجعوا حقوقه ضمن سياسة الشركة. لأن حقوق المجموعات تتراكم، فنقله دون سحب القديم يعطيه مجموع الدورين.
ردود أفعال الفريق
قد يفهم فريق المبيعات تضييق الرؤية على أنه عدم ثقة. اشرحوا أن الهدف تحديد العمل لا مراقبة الأشخاص، وحدّدوا قناة لطلب صلاحية إضافية يوافق عليها مالك العملية. ويظل اعتماد المستند المالي مرتبطًا بسير الموافقة الذي اختبرته الإدارة.
أسئلة شائعة
هل يكفي إخفاء القائمة لحماية البيانات؟ لا. هو تنظيم للواجهة، والتحقق يكون بحقوق النموذج وقواعد السجلات واختبار الحساب 1.
هل إذن التعديل يعني الموافقة المالية؟ لا. الموافقة سير عمل مستقل يُصمَّم ويُختبر بحسابات أصحاب الأدوار.
ماذا نفعل عند نقل موظف إلى قسم آخر؟ راجع عضوياته القديمة والجديدة وصلاحياته مع مالك العملية، ثم اختبر ما أصبح مسموحًا وما يجب أن يتوقف ضمن سياسة الشركة.
الخطوة التالية
اجمعوا المالك ومدير المالية ومسؤول المشتريات ومسؤول المستودع، واتفقوا على المصفوفة، ثم حوّلوها إلى حالات اختبار في نسخة معزولة. لرؤية دورة بيع ومخزون ببيانات افتراضية قبل النقاش، جرّبوا المحاكاة الموجهة؛ وهي ليست بيئة لضبط الصلاحيات ولا محاكاة لكل التطبيقات. وراجعوا تطبيقات اودو والقطاعات لتحديد ما يخص تشغيلكم، واستخدموا الحاسبات لتقدير افتراضي للتكلفة والوقت. وإن رغبتم في أن يتواصل معكم فريقنا، فاطلبوا ذلك عبر صفحة التواصل. وللعودة إلى تعريف الخدمة: تودو اوبس.
المراجع
[1] اودو — التوثيق الرسمي19.0. راجعنا Access rights وSecurity in Odoo بتاريخ3نوفمبر2026: حقوق المجموعات على النماذج، وقواعد السجلات وتراكم الصلاحيات، والبوابة وحسابات المستخدمين.
[2] الهيئة الوطنية للأمن السيبراني — ضوابط الأمن السيبراني الأساسيةECC2-2024. الصفحات المطبوعة19–20 من النسخة الإنجليزية العامة، البنود2.2.3.3–2.2.3.5: أقل صلاحية وفصل المهام وإدارة الوصول المميز والمراجعة الدورية للهويات والصلاحيات.