الانتقال إلى المحتوى
Access

إدارة المستخدمين والشركات والصلاحيات (UserCompanyManagement)

الهوية والوصول

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

المجال
البنية التحتية للمنصة / RBAC وتعدد المستأجرين
العملاء المستهدفون
المجموعات المالية التي تضم عدة شركات تابعة أو عدة مستأجرين مستقلين؛ مديرو تقنية المعلومات الذين يفصلون صلاحيات الموظفين بين الشركات
القدرات الرئيسية
إدارة Tenant/Company/Branch، RBAC بمستويين (Controls+UIPermissions)، ResolveUserContext، كتالوج صلاحيات تلقائي لكل خدمة، TenantDatabaseMap، التخزين المؤقت للصلاحيات في Redis

تملك UserCompanyManagement «هوية الأعمال» في المنصة: ملفات المستخدمين والشركات والفروع، وعضوية المستخدم في الشركة، ونظام الأدوار والصلاحيات بأكمله (RBAC). صُمّمت الخدمة لتعدد المستأجرين (multi-tenant): يمكن لكل Tenant أن يضم عدة شركات، ولكل شركة مستخدموها وفروعها وصلاحياتها بصورة مستقلة.

النقطة المعمارية المحورية فيها واجهة API باسم ResolveUserContext: عند تسجيل دخول مستخدم، تستدعي خدمة Identity هذه الخدمة لبناء claims رمز الوصول (الأدوار والصلاحيات والشركات). وبالمثل، يحدد TenantDatabaseMap قاعدة البيانات التي تستخدمها كل شركة في كل خدمة أخرى، وهو أساس معمارية تعدد المستأجرين في المنصة بأكملها.

يقوم نظام الصلاحيات على نموذج Permission-per-UserCompany: تُمنح كل صلاحية للعلاقة «مستخدم في شركة محددة» لا للمستخدم بمفرده، أي يمكن للمستخدم الواحد أن يكون مديرًا في الشركة A وموظفًا عاديًا في الشركة B. وقد فُصل نوعان من الصلاحيات: Controls لعمليات API (لكل endpoint صلاحية واحدة) وUIPermissions للتحكم في ظهور القوائم والصفحات في اللوحة. ومن النقاط المعمارية المهمة أن ملكية صلاحيات كل خدمة تُعرَّف في الخدمة نفسها (وليس في UserCompanyManagement)؛ إذ تعلن كل خدمة مصغّرة عند الإقلاع قائمة صلاحياتها إلى هذه الخدمة عبر sync-service، وتحتفظ بها UserCompanyManagement ككتالوج مركزي وتخزّنها مؤقتًا.

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

القدرات والإمكانات الرئيسية

  • إدارة تعدد المستأجرين Tenant/Company/Branch

    لكل Tenant عدة شركات، ولكل شركة عدة فروع؛ ويمكن للمستخدم أن يكون عضوًا في عدة شركات بأدوار مختلفة في كل منها.

  • RBAC بطبقتين: Controls وUIPermissions

    Controls لكل عملية API وUIPermissions لإظهار القوائم والصفحات أو إخفائها؛ ويتم التخصيص على مستوى الدور وعلى مستوى العلاقة المباشرة بين المستخدم والشركة.

  • ResolveUserContext لخدمة Identity

    لحظة تسجيل الدخول، تُقرأ من هذه الخدمة أدوار المستخدم وصلاحياته وقائمة شركاته لبناء رمز الوصول.

  • كتالوج صلاحيات يتحدث تلقائيًا (Permission Sync)

    تعلن كل خدمة جديدة أو وحدة جديدة صلاحياتها عند startup (sync-service)؛ وتتم الإضافة والتحديث والحذف تلقائيًا، وتُمنح الصلاحية الجديدة تلقائيًا لجميع مستخدمي SuperAdmin أيضًا.

  • التسجيل العام وإدارة المستخدمين

    مسار تسجيل عام عبر الجوال لا يحتاج إلى JWT، مع التحقق عبر OTP.

  • TenantDatabaseMap

    ربط كل شركة بقاعدة بياناتها الخاصة في كل خدمة، مع تخزين مؤقت لمدة 5 دقائق، وهو أساس عزل البيانات في معمارية تعدد المستأجرين.

  • التخزين المؤقت للصلاحيات في Redis

    تُخزَّن صلاحيات كل مستخدم في كل شركة مؤقتًا بالمفتاح {service}:permissions:{userId}:{companyId}، وتُبطَل عند أي تغيير في الدور أو الصلاحيات.

  • التخصيص الجماعي للصلاحيات

    منح صلاحيات دور ما لعدة علاقات مستخدم-شركة دفعة واحدة، بصورة تراكمية (دون حذف الصلاحيات السابقة).

القيمة للأعمال

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

سيناريوهات الاستخدام

  • مجموعة مالية لديها عدة شركات تابعة، ويعمل فيها موظفون مشتركون بين بعض الشركات بأدوار مختلفة.
  • تهيئة سريعة لمستأجر (tenant) جديد بشركته وفرعه ومستخدم مسؤول أولي، دون التدخل في الشيفرة.
  • إضافة خدمة مصغّرة جديدة إلى المنصة بحيث تتوفر منذ يومها الأول صلاحيات API وصفحات UI الخاصة بها في لوحة المسؤول وكتالوج الصلاحيات.
  • إغلاق وصول مستخدم إلى شركة معينة أو تقييده، دون التأثير على عضويته في الشركات الأخرى.
Get in Touch

شاهدوا هذه الوحدة على بيانات تجريبية

في الجلسة التعريفية نستعرض سيناريوهات مؤسستك على النسخة التجريبية من دارا، ونجيب عن أسئلة فريقيك التقني والمالي.