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