التحكم في الوصول القائم على القواعد

الأدوار والأذونات والمستخدمون في OmniCRM

يستخدم OmniCRM التحكم في الوصول القائم على الأدوار (RBAC): يتم تعيين الأشخاص (المستخدمون) لدور واحد أو أكثر، وكل دور هو مجموعة من الأذونات. الأذونات هي أصغر وحدة من الوصول (مثل، view_customer, create_inventory). الوصول الفعلي للمستخدم هو اتحاد الأذونات من جميع الأدوار المعينة.

الغرض

يمكن لـ RBAC:

1. حماية البيانات --- يرى المستخدمون فقط ما يُسمح لهم برؤيته.
2. تناسب العمليات --- تعكس الأدوار وظائف العمل (الإدارة، الدعم، المالية، إدارة العملاء).
3. إدارة بسيطة --- منح الوصول عن طريق تعيين الأدوار؛ تجنب الإدارة الدقيقة لكل مستخدم.
4. عزل المستأجرين --- تحد أ��ونات "رؤية الخاصة ..." من الرؤية لبيانات العملاء/المستأجرين الخاصة بالمستخدم.

كيف تتناسب المستخدمون والأدوار والأذونات معًا

• المستخدمون --- أشخاص حقيقيون يقومون بتسجيل الدخول إلى OmniCRM.
• الأذونات --- قدرات ذرية (مثل، view_customer, delete_product).
• الأدوار --- مجموعات مسماة من الأذونات (مثل، Admin, Support, Finance).
• التعيين --- يتلقى المستخدمون دورًا أو أكثر؛ تتجمع الأذونات.

يثبت المصادقة من أنت (JWT، مفتاح API، أو عنوان IP مدرج في القائمة البيضاء). تحدد التفويض (الأدوار/الأذونات) ما يمكنك القيام به.

إدارة المستخدمين

يسمح نظام إدارة المستخدمين في OmniCRM للمسؤولين بإنشاء وإدارة مستخدمي الموظفين (المسؤولين، وكلاء خدمة العملاء)، وعرض وتعديل أدوار المستخدمين، وإعادة تعيين كلمات المرور، وإدارة الم��ادقة الثنائية، والتحكم في وصول المستخدمين.

أنواع المستخدمين

مستخدمو العملاء - يتم إنشاؤهم عبر التسجيل الذاتي أو بواسطة المسؤولين. يتم تعيينهم تلقائيًا لدور "العميل". يمكن لهؤلاء المستخدمين الوصول إلى بوابة الرعاية الذاتية لإدارة خدماتهم، وعرض الاستخدام، ودفع الفواتير، إلخ.

مستخدمو الموظفين - يتم إنشاؤهم بواسطة المسؤولين الذين لديهم الأذونات المناسبة. يمكن تعيينهم لأدوار مثل الإدارة، الدعم، المالية، إلخ. يمكن لهؤلاء المستخدمين الوصول إلى واجهة CRM لإدارة العملاء، وتوفير الخدمات، والتعامل مع الفواتير، إلخ.

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

يتم إنشاء المستخدم الإداري الأول بواسطة فريق Omnitouch عند نشر النظام.

إضافة مستخدمين جدد (المسؤولون وCSAs)

يمكن للمسؤولين إنشاء مستخدمين جدد من الموظفين من خلال واجهة الويب أو API.

عبر واجهة الويب

1. انتقل إلى المستخدمين والأدوار - الوصول إلى واجهة إدارة المستخدم من قائمة الإدارة
2. انقر على "إضافة مستخدم" - يفتح نموذج إنشاء المستخدم

3. املأ تفاصيل المستخدم:
   • اسم المستخدم - اسم مستخدم فريد لتسجيل الدخول (مطلوب)
   • البريد الإلكتروني - عنوان البريد الإلكتروني للمستخدم (مطلوب، يجب أن يكون فريدًا)
   • كلمة المرور - كلمة مرور مؤقتة (مطلوبة، يجب على المستخدم تغييرها عند تسجيل الدخول لأول مرة)
   • الاسم الأول - الاسم الأول للمستخدم (مطلوب)
   • اسم الأب - اسم الأب للمستخدم (اختياري)
   • اسم العائلة - اسم العائلة للمستخدم (مطلوب)
   • رقم الهاتف - رقم الهاتف للتواصل (اختياري)
   • الدور - اختر دورًا أو أكثر للتعيين (مطلوب)
   • جهة اتصال العميل - ربط المستخدم بسجل جهة اتصال العميل (للمستخدمين العملاء)
4. انقر على "إنشاء مستخدم" - يتم إنشاء المستخدم ويمكنه تسجيل الدخول على الفور باستخدام بيانات الاعتماد المقدمة
5. يتلقى المستخدم إشعارًا - إرسال بريد إلكتروني ترحيبي اختياري مع تعليمات تسجيل الدخول

أفضل الممارسات:

• استخدم كلمة مرور مؤقتة مثل TempP@ssw0rd! واطلب من المستخدم تغييرها عند تسجيل الدخول لأول مرة
• تعيين الأدوار المناسبة بناءً على وظيفة العمل (انظر تصميمات الأدوار النموذجية أدناه)
• تمكين 2FA لجميع الموظفين الإداريين والدعم
• ربط المستخدمين العملاء بسجل جهة اتصال العميل الخاص بهم لتحديد البيانات بشكل صحيح

عبر API

إنشاء مستخدم برمجيًا:

نقطة النهاية: POST /auth/users

إذن مطلوب: admin

جسم الطلب:

{
  "username": "john.smith",
  "email": "john.smith@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "John",
  "middle_name": "D",
  "last_name": "Smith",
  "phone_number": "+61412345678",
  "role": "Support"
}

الاستجابة:

{
  "id": 123,
  "username": "john.smith",
  "email": "john.smith@company.com",
  "first_name": "John",
  "last_name": "Smith",
  "roles": ["Support"],
  "created": "2025-01-04T10:30:00Z"
}

تعيين أدوار متعددة:

يمكن أن يكون للمستخدمين أدوار متعددة. الأذونات تضاف (اتحاد جميع أذونات الدور المعينة).

لتعيين أدوار متعددة، قم بتضمينها في الطلب:

{
  "username": "jane.doe",
  "email": "jane.doe@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "Support,Finance"
}

أو استخدم نقطة نهاية تعيين الدور بعد إنشاء المستخدم:

POST /auth/roles/{role_id}/users/{user_id}

عرض والبحث عن المستخدمين

قائمة جميع المستخدمين (المسؤول):

GET /auth/users

يُرجع قائمة مجزأة من جميع المستخدمين مع أدوارهم ومعلومات أساسية.

بحث عن المستخدمين:

GET /auth/users/search?search={query}&filters={"role":["Support"]}&page=1&per_page=50

تصفية حسب:

• اسم الدور
• نطاق البريد الإلكتروني
• حالة النشاط/الحذف
• حالة تمكين 2FA
• تاريخ آخر تسجيل دخول

الحصول على مستخدم محدد:

GET /auth/users/{user_id}

يُرجع تفاصيل المستخدم الكاملة بما في ذلك:

• المعلومات الشخصية
• الأدوار المعينة والأذونات الفعالة
• حالة 2FA
• آخر تسجيل دخول ومعلومات الجلسة
• جهة اتصال العميل المرتبطة (إذا كان ذلك مناسبًا)

إنشاء وإدارة الأدوار

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

إنشاء دور جديد

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → علامة التبويب الأدوار
2. انقر على "إنشاء دور"
3. أدخل تفاصيل الدور:
   • الاسم - اسم قصير ووصف (مثل، "Tier2_Support")
   • الوصف - شرح غرض الدور ومسؤولياته
4. انقر على "إنشاء"
5. يتم إنشاء الدور بدون أذونات؛ أضف الأذونات في الخطوة التالية

عبر API:

نقطة النهاية: POST /auth/roles

إذن مطلوب: admin

الطلب:

{
  "name": "Tier2_Support",
  "description": "Level 2 support team with elevated provisioning access"
}

الاستجابة:

{
  "id": 45,
  "name": "Tier2_Support",
  "description": "Level 2 support team with elevated provisioning access",
  "permissions": [],
  "users": []
}

إضافة أذونات إلى دور

بمجرد إنشاء دور، قم بتعيين الأذونات لتحديد ما يمكن للمستخدمين الذين لديهم هذا الدور القيام به.

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → علامة التبويب الأدوار
2. انقر على اس�� الدور لعرض التفاصيل
3. في قسم الأذونات، انقر على "إضافة إذن"
4. اختر واحدًا أو أكثر من الأذونات من القائمة
5. انقر على "إضافة" - يتم تعيين الأذونات على الفور

عبر API:

نقطة النهاية: POST /auth/roles/{role_id}/permissions

الطلب:

{
  "permission_id": 123
}

أو أضف أذونات متعددة:

{
  "permission_ids": [123, 124, 125]
}

مثال: إنشاء دور "أخصائي توفير"

يمكن لهذا الدور عرض العملاء، وإدارة الخدمات، والتوفير:

1. إنشاء الدور:

   POST /auth/roles
   {
     "name": "Provisioning_Specialist",
     "description": "Can provision services and manage customer services"
   }

2. إضافة الأذونات:

   POST /auth/roles/45/permissions
   {
     "permission_ids": [
       1,   # view_customer
       20,  # view_customer_service
       21,  # create_customer_service
       22,  # update_customer_service
       30,  # view_provision
       31,  # create_provision
       40,  # view_inventory
       50,  # view_product
     ]
   }

إزالة الأذونات من دور

عبر واجهة الويب:

1. انتقل إلى تفاصيل الدور
2. في قائمة الأذونات، انقر على "X" أو زر "إزالة" بجوار الإذن
3. تأكيد الإزالة

عبر API:

نقطة النهاية: DELETE /auth/roles/{role_id}/permissions/{permission_id}

مثال:

DELETE /auth/roles/45/permissions/31

هذا يزيل إذن create_provision من الدور.

تحرير تفاصيل الدور

تحديث اسم الدور أو الوصف:

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → علامة التبويب الأدوار
2. انقر على الدور لتحريره
3. تعديل اسم الدور أو الوصف
4. انقر على "حفظ"

عبر API:

نقطة النهاية: PUT /auth/roles/{role_id}

{
  "name": "Senior_Support",
  "description": "Senior support team with full customer access"
}

حذف دور

تحذير: يؤدي حذف دور إلى إ��الته من جميع المستخدمين المعينين. تأكد من أن لدى المستخدمين أدوار بديلة أو سيفقدون الوصول.

عبر API:

DELETE /auth/roles/{role_id}

أفضل ممارسة: بدلاً من الحذف، اعتبر أرشفة أو إعادة تسمية الأدوار التي لم تعد مطلوبة.

تعيين الأدوار للمستخدمين

أثناء إنشاء المستخدم:

تضمين الدور في طلب إنشاء المستخدم (انظر "إضافة مستخدمين جدد" أعلاه).

للمستخدمين الحاليين:

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → علامة التبويب المستخدمون
2. انقر على المستخدم لتحريره
3. في قسم الأدوار، حدد/ألغِ تحديد الأدوار
4. انقر على "حفظ"

عبر API:

تحديث أدوار المستخدم:

نقطة النهاية: PUT /auth/users/{user_id}

{
  "role": "Support,Finance"
}

أو تعيين دور واحد لمستخدم عبر نقطة نهاية الدور:

نقطة النهاية: POST /auth/roles/{role_id}/users/{user_id}

عرض تعيينات الأدوار

جميع المستخدمين في دور:

GET /auth/roles/{role_id}/users

يُرجع قائمة بجميع المستخدمين المعينين لذلك الدور.

جميع الأدوار لمستخدم:

GET /auth/users/{user_id}

تتضمن الاستجابة مصفوفة roles مع جميع الأدوار المعينة.

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

يوفر OmniCRM طرقًا متعددة لإدارة كلمات المرور اعتمادًا على السياق.

إعادة تعيين كلمة المرور لخدمة المستخدم الذاتية

يمكن للمستخدمين الذين نسوا كلمة مرورهم إعادة تعيينها بأنفسهم عبر صفحة تسجيل الدخول:

1. انقر على "نسيت كلمة المرور" على صفحة تسجيل الدخول
2. أدخل عنوان البريد الإلكتروني - يرسل النظام بريدًا إلكترونيًا لإعادة تعيين كلمة المرور
3. تحقق من البريد الإلكتروني - يحتوي البريد الإلكتروني على رابط إعادة تعيين آمن مع رمز (صالح لمدة ساعة واحدة)
4. انقر على الرابط - يفتح نموذج إعادة تعيين كلمة المرور
5. أدخل كلمة المرور الجديدة - يجب أن تلبي متطلبات تعقيد كلمة المرور:
   • الحد الأدنى 8 أحرف
   • على الأقل حرف كبير واحد
   • على الأقل حرف صغير واحد
   • على الأقل رقم واحد
   • على الأقل رمز خاص واحد
6. إرسال - يتم تحديث كلمة المرور على الفور؛ يمكن للمستخدم تسجيل الدخول باستخدام كلمة المرور الجديدة

تدفق API:

1. طلب إعادة التعيين:

   نقطة النهاية: POST /auth/forgot_password

   {
     "email": "user@example.com"
   }

   يقوم النظام بإنشاء رمز إعادة التعيين ويرسل البريد الإلكتروني.

2. إعادة التعيين باستخدام الرمز:

   نقطة النهاية: POST /auth/reset_password

   {
     "token": "abc123...",
     "new_password": "NewSecureP@ssw0rd!"
   }

إعادة تعيين كلمة المرور من قبل المسؤول

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

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → المستخدمون
2. ابحث عن المستخدم وانقر على زر "إعادة تعيين كلمة المرور"
3. أدخل كلمة مرور مؤقتة
4. انقر على "إعادة تعيين"
5. أبلغ المستخدم بكلمة المرور المؤقتة الخاصة به (عبر قناة آمنة)
6. يجب على المستخدم تغيير كلمة المرور عند تسجيل الدخول التالي

عبر API:

نقطة النهاية: POST /auth/users/{user_id}/admin_reset_password

إذن مطلوب: admin

الطلب:

{
  "new_password": "TempP@ssw0rd!",
  "force_change": true
}

المعلمات:

• new_password - كلمة المرور المؤقتة التي سيتم تعيينها
• force_change (اختياري) - إذا كانت صحيحة، يجب على المستخدم تغيير كلمة المرور عند تسجيل الدخول التالي

تغيير المستخدم لكلمة المرور الخاصة به

يمكن للمستخدمين المصرح لهم تغيير كلمة مرورهم الخاصة من ملفهم الشخصي:

نقطة النهاية: POST /auth/change_password

الطلب:

{
  "current_password": "OldP@ssw0rd!",
  "new_password": "NewSecureP@ssw0rd!"
}

يتحقق النظام من كلمة المرور الحالية قبل السماح بالتغيير.

أمان كلمة المرور

• يتم تجزئة كلمات المرور باستخدام bcrypt (أمان Werkzeug)
• لا يتم تخزينها بنص عادي
• تنتهي صلاحية رموز إعادة التعيين بعد ساعة واحدة
• يمكن أن تؤدي محاولات تسجيل الدخول الفاشلة إلى قفل الحساب (قابل للتكوين)
• تتبع تاريخ كلمة المرور يمنع إعادة الاستخدام (قابل للتكوين)
• يتم فرض متطلبات التعقيد

إدارة المصادقة الثنائية (2FA)

يدعم OmniCRM المصادقة الثنائية المعتمدة على TOTP لتعزيز الأمان. يمكن للمسؤولين تمكين وتعطيل وإعادة تعيين 2FA للمستخدمين.

تمكين 2FA لمستخدم

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → المستخدمون
2. انقر على المستخدم لعرض التفاصيل
3. في قسم الأمان، انقر على "تمكين 2FA"
4. يقوم النظام بإنشاء:
   • سر TOTP (يتم عرض رمز QR)
   • 10 رموز احتياطية (للاستخدام لمرة واحدة)
5. يقوم المستخدم بمسح رمز QR باستخدام تطبيق المصادقة (Google Authenticator، Authy، إلخ.)
6. يدخل المستخدم رمز التحقق من التطبيق لتأكيد الإعداد
7. يقوم المستخدم بحفظ الرموز الاحتياطية في مكان آمن
8. تم تمكين 2FA الآن؛ مطلوب لجميع تسجيلات الدخول المستقبلية

عبر API:

1. إنشاء سر TOTP:

   نقطة النهاية: POST /2fa/enable/user/{user_id}

   الاستجابة:

   {
     "totp_secret": "JBSWY3DPEHPK3PXP",
     "qr_code_url": "otpauth://totp/OmniCRM:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=OmniCRM",
     "backup_codes": [
       "12345678",
       "23456789",
       "34567890",
       ...
     ]
   }

2. التحقق من الإعداد:

   نقطة النهاية: POST /2fa/verify-setup/user/{user_id}

   {
     "code": "123456"
   }

   تُرجع {"verified": true} عند النجاح.

تدفق تسجيل الدخول 2FA

بمجرد تمكين 2FA، يتغير عملية تسجيل الدخول:

1. يدخل المستخدم اسم المستخدم وكلمة المرور
2. يتحقق النظام من بيانات الاعتماد
3. إذا كانت صحيحة، يطلب رمز 2FA
4. يدخل المستخدم الرمز من تطبيق المصادقة أو الرمز الاحتياطي
5. يتحقق النظام من الرمز
6. عند النجاح، يتم تسجيل دخول المستخدم

الرموز الاحتياطية:

• تم إنشاء 10 رموز أثناء إعداد 2FA
• للاستخدام لمرة واحدة فقط (تستهلك بعد الاستخدام)
• تستخدم إذا كان تطبيق المصادقة غير متاح
• يمكن إعادة إنشائها بواسطة المستخدم أو المسؤول

التحقق من رمز 2FA

نقطة النهاية: POST /2fa/verify/user/{user_id}

{
  "code": "123456"
}

يقبل كلا من:

• رمز TOTP (6 أرقام من تطبيق المصادقة)
• رمز احتياطي (8 أرقام من قائمة الرموز الاحتياطية)

إعادة إنشاء الرموز الاحتياطية

إذا استنفد المستخدم الرموز الاحتياطية أو فقدها، قم بإنشاء رموز جديدة:

عبر واجهة الويب:

1. انتقل إلى تفاصيل المستخدم
2. انقر على "إعادة إنشاء الرموز الاحتياطية"
3. عرض أو إرسال الرموز الجديدة إلى المستخدم
4. تصبح الرموز القديمة غير صالحة

عبر API:

نقطة النهاية: POST /2fa/backup-codes/regenerate/user/{user_id}

الاستجابة:

{
  "backup_codes": [
    "98765432",
    "87654321",
    "76543210",
    ...
  ]
}

إعادة تعيين 2FA من قبل المسؤول

إذا فقد المستخدم الوصول إلى تطبيق المصادقة الخاص به وجميع الرموز الاحتياطية، يمكن للمسؤول تعطيل وإعادة تمكين 2FA.

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → المستخدمون
2. انقر على المستخدم
3. انقر على زر "إعادة تعيين 2FA"
4. تأكيد إعادة التعيين
5. يتم تعطيل 2FA؛ يمكن للمستخدم تسجيل الدخول باستخدام كلمة المرور فقط
6. إرشاد المستخدم لإعداد 2FA مرة أخرى مع السر الجديد

عبر API:

نقطة النهاية: POST /2fa/admin/disable/user/{user_id}

إذن مطلوب: admin

هذا يعطل 2FA تمامًا للمستخدم:

• يتم مسح سر TOTP
• يتم مسح الرموز الاحتياطية
• يتم تعيين علامة is_2fa_enabled إلى false

يمكن للمستخدم بعد ذلك إعادة تمكين 2FA للحصول على سر جديد ورموز احتياطية.

إعادة تعيين 2FA لخدمة المستخدم الذاتية (جهاز جديد)

إذا حصل المستخدم على جهاز جديد ولكنه لا يزال لديه وصول إلى الرموز الاحتياطية:

نقطة النهاية: POST /2fa/reset-for-new-device/user/{user_id}

{
  "backup_code": "12345678"
}

يتحقق النظام من الرمز الاحتياطي، ثم ينشئ سر TOTP جديد ورموز احتياطية. يمكن للمستخدم إعداد تطبيق المصادقة على الجهاز الجديد.

أفضل الممارسات لـ 2FA

• يتطلب 2FA لجميع الموظفين الإداريين والدعم
• تخزين الرموز الاحتياطية بأمان (مدير كلمات المرور أو ملاحظة آمنة)
• إعادة إنشاء الرموز الاحتياطية بعد استخدام عدة منها
• استخدام تطبيقات المصادقة ذات السمعة الطيبة (Google Authenticator، Authy، Microsoft Authenticator)
• توثيق إجراءات إعادة تعيين 2FA لموظفي الدعم
• تدقيق استخدام 2FA - مراقبة المستخدمين الذين لديهم 2FA مفعل

تحديث معلومات المستخدم

يمكن للمسؤولين تحديث تفاصيل المستخدم في أي وقت.

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → المستخدمون
2. انقر على المستخدم لتحريره
3. تعديل أي حقول قابلة للتحرير:
   • الاسم الأول، اسم الأب، اسم العائلة
   • عنوان البريد الإلكتروني (يتطلب التحقق)
   • رقم الهاتف
   • الأدوار
   • ربط جهة اتصال العميل
4. انقر على "حفظ"

عبر API:

نقطة النهاية: PUT /auth/users/{user_id}

{
  "first_name": "Jane",
  "last_name": "Doe-Smith",
  "email": "jane.doesmith@newcompany.com",
  "phone_number": "+61498765432",
  "role": "Support,Finance"
}

تغييرات البريد الإلكتروني:

عند تغيير البريد الإلكتروني، يتم وضع البريد الإلكتروني الجديد في حالة الانتظار حتى يتم التحقق منه:

• يتم تخزين البريد الإلكتروني الجديد في حقل pending_email
• يتم إرسال بريد إلكتروني للتحقق إلى العنوان الجديد
• ينقر المستخدم على الرابط للتحقق
• يتم تحديث حقل email إلى القيمة الجديدة
• يتم تعيين علامة email_verified إلى true

حذف المستخدمين

يستخدم OmniCRM الحذف الناعم للمستخدمين - يتم وضع علامة عليهم كحذف ولكن لا تتم إزالتهم من قاعدة البيانات. هذا يحافظ على ��جلات التدقيق والبيانات التاريخية.

حذف مستخدم

عبر واجهة الويب:

1. انتقل إلى المستخدمون والأدوار → المستخدمون
2. ابحث عن المستخدم المراد حذفه
3. انقر على زر "حذف"
4. تأكيد الحذف
5. يتم تسجيل خروج المستخدم على الفور ولا يمكنه تسجيل الدخول مرة أخرى

عبر API:

نقطة النهاية: DELETE /auth/users/{user_id}

إذن مطلوب: admin

ماذا يحدث:

• يتم تعيين علامة deleted إلى True
• يتم تسجيل الطابع الزمني deleted_at
• لا يمكن للمستخدم تسجيل الدخول
• يتم إبطال جميع الجلسات النشطة
• لا يزال يظهر المستخدم في سجلات التدقيق والسجلات التاريخية
• يتم الحفاظ على البيانات المرتبطة (جهات اتصال العملاء، الأنشطة)

عرض المستخدمين المحذوفين

تصفية المستخدمين المحذوفين:

GET /auth/users/search?filters={"deleted":[true]}

استعادة مستخدم محذوف

إذا تم حذف مستخدم عن طريق الخطأ، يمكن للمسؤولين استعادته:

نقطة النهاية: PUT /auth/users/{user_id}

{
  "deleted": false
}

هذا clears the deleted flag ويتيح للمستخدم تسجيل الدخول مرة أخرى.

ملاحظة: تظل كلمة مرور المستخدم دون تغيير، لذا يمكنه استخدام كلمة المرور السابقة.

حذف مستخدم بشكل دائم

تحذير: هذا غير قابل للتراجع ويزيل جميع بيانات المستخدم من قاعدة البيانات.

لا يتم الكشف عنها عبر واجهة المستخدم. متاحة فقط عبر الوصول المباشر إلى قاعدة البيانات لأسباب الامتثال (مثل، طلبات حذف البيانات وفقًا لـ GDPR).

أفضل الممارسات لحذف المستخدمين

• حذف ناعم بشكل افتراضي - يحافظ على سجلات التدقيق
• توثيق أسباب الحذف - إضافة ملاحظة في سجل النشاط قبل الحذف
• نقل الملكية - إعادة تعيين التذاكر المفتوحة والمهام الخاصة بالمستخدم قبل الحذف
• مراجعة الوصول - التأكد من عدم اعتماد أي عمليا�� حرجة على المستخدم
• أرشفة البيانات - تصدير تاريخ عمل المستخدم إذا لزم الأمر
• إبلاغ الفرق المعنية - إعلام المديرين/الزملاء بالحذف

كتالوج الأذونات

تتبع الأذونات عمومًا أنماط CRUD:

• view\_\* --- قراءة/تصفح
• create\_\* --- إنشاء/إضافة
• update\_\* --- تعديل/تغيير
• delete\_\* --- حذف/إزالة

تشمل بعض الكيانات أيضًا متغيرات "رؤية الخاصة ..." التي تحد من الرؤية لبيانات العميل/المستأجر الخاصة بالمستخدم.

عالمي / إداري

• admin --- وصول إداري كامل (إدارة المستخدمين والأدوار والأذونات؛ الوصول إلى جميع نقاط النهاية المحمية).
• can_impersonate --- التصرف مؤقتًا كـ مستخدم آخر (تدقيق؛ للدعم/استكشاف الأخطاء وإصلاحها).

العملاء والسجلات ذات الصلة

• العميل
  • view_customer, create_customer, update_customer, delete_customer
  • نطاق خاص: رؤية العميل الخاص
• موقع العميل
  • view_customer_site, create_customer_site, update_customer_site, delete_customer_site
  • نطاق خاص: رؤية موقع العميل الخاص
• جهة اتصال العميل
  • view_customer_contact, create_customer_contact, update_customer_contact, delete_customer_contact
  • نطاق خاص: رؤية جهة اتصال العميل الخاصة
• سمة العميل (انظر سمات العميل)
  • view_customer_attribute, create_customer_attribute, update_customer_attribute, delete_customer_attribute
  • نطاق خاص: رؤية سمة العميل الخاصة
• علامة العميل (انظر علامات العميل)
  • view_customer_tag, create_customer_tag, update_customer_tag, delete_customer_tag
  • نطاق خاص: رؤية علامة العميل الخاصة
• خدمة العميل
  • view_customer_service, create_customer_service, update_customer_service, delete_customer_service
  • نطاق خاص: رؤية خدمة العميل الخاصة
• نشاط العميل
  • view_customer_activity, create_customer_activity, update_customer_activity, delete_customer_activity
  • نطاق خاص: رؤية نشاط العميل الخاص

الفوترة

• بطاقة Stripe
  • view_customer_stripe_card, create_customer_stripe_card, update_customer_stripe_card, delete_customer_stripe_card
  • نطاق خاص: رؤية بطاقة Stripe الخاصة بالعميل
• المعاملات
  • view_customer_transaction, create_customer_transaction, update_customer_transaction, delete_customer_transaction
  • نطاق خاص: رؤية المعاملة الخاصة بالعميل
• الفواتير
  • view_customer_invoice, create_customer_invoice, update_customer_invoice, delete_customer_invoice
  • نطاق خاص: رؤية الفاتورة الخاصة بالعميل

الاتصالات

• view_communication, create_communication, update_communication, delete_communication
• نطاق خاص: رؤية الاتصال الخاص

المخزون والقوالب

• المخزون
  • view_inventory, create_inventory, update_inventory, delete_inventory
  • نطاق خاص: رؤية المخزون الخاص
• قالب المخزون
  • view_inventory_template, create_inventory_template, update_inventory_template, delete_inventory_template
  • نطاق خاص: رؤية قالب المخزون الخاص

المنتجات

• view_product, create_product, update_product, delete_product

بث الخلايا (CBC)

• view_cbc_message, create_cbc_message, update_cbc_message, delete_cbc_message

التوفير

• توفير
  • view_provision, create_provision, update_provision, delete_provision
  • نطاق خاص: رؤية التوفير الخاص
• حدث التوفير
  • view_provision_event, create_provision_event, update_provision_event, delete_provision_event

الوصول "رؤية الخاصة"

تحدد أذونات "رؤية الخاصة ..." قراءات (وربما تعديلات، حيث تم تنفيذها) للبيانات المرتبطة بـ عميل/مستأجر المستخدم الخاص. على سبيل المثال، يمكن لدور مدير العميل إدارة جهات اتصال مستأجرهم، والمواقع، والفواتير، والخدمات، ولكن لا يمكنهم رؤية مستأجرين آخرين.

تصميمات الأدوار النموذجية

الدور الأذونات النموذجية الملاحظات

---

مسؤول النظام admin، اختياريًا can_impersonate؛ بالإضافة إلى CRUD واسع حسب الحاجة السيطرة الكاملة على المستخدمين/الأدوار/الأذونات الدعم view_customer، view_customer_service، view_communication، view_provision؛ تحديثات اختيارية إضافة can_impersonate إذا كان مسموحًا المالية view_customer_invoice، view_customer_transaction، view_product؛ اختياري create_customer_invoice ثقيلة القراءة؛ كتابة محدودة مدير العميل (المستأجر) "رؤية الخاصة ..." عبر العملاء، المواقع، جهات الاتصال، الخدمات، المخزون، الفواتير، المعاملات، الاتصالات، التوفير إدارة محددة للمستأجر المدقق ذو القراءة فقط view_* فقط لا إنشاء/تحديث/حذف

: مثال على الأدوار والأذونات المضمنة (ملخص)

إدارة الأدوار والأذونات عبر API

تتطلب جميع نقاط النهاية إذن admin.

قائمة الأذونات

نقطة النهاية: GET /auth/permissions

إنشاء إذن (نادر)

نقطة النهاية: POST /auth/permissions

جسم الطلب:

{
    "name": "view_example",
    "description": "Read-only access to example objects"
}

قائمة الأدوار

نقطة النهاية: GET /auth/roles

إنشاء دور

نقطة النهاية: POST /auth/roles

جسم الطلب:

{
"name": "Support",
"description": "Tier-1 support team"
}

إضافة إذن إلى دور

نقطة النهاية: POST /auth/roles/{role_id}/permissions

جسم الطلب:

{
  "permission_id": 123
}

إزالة إذن من دور

نقطة النهاية: DELETE /auth/roles/{role_id}/permissions/{permission_id}

تعيين الأدوار للمستخدمين

إنشاء مستخ��م مع دور

نقطة النهاية: POST /auth/users

جسم الطلب:

{
  "username": "sara",
  "email": "sara@example.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Sara",
  "last_name": "Ng",
  "phone_number": "+61...",
  "role": "Support"
}

تحديث دور مستخدم

نقطة النهاية: PUT /auth/users/{user_id}

جسم الطلب:

{
  "role": "Finance"
}

قائمة المستخدمين (فقط للمسؤولين)

نقطة النهاية: GET /auth/users

انتحال الشخصية (مراقب)

• مطلوب: can_impersonate أو admin

بدء انتحال الشخصية

نقطة النهاية: POST /auth/impersonate

جسم الطلب:

{ "user_id": 42 }

إيقاف انتحال الشخصية

نقطة النهاية: POST /auth/stop_impersonation

أفضل الممارسات

• أقل امتياز أولاً. ابدأ بأدوار الحد الأدنى؛ أضف الأذونات حسب الحاجة.
• يفضل "رؤية الخاصة ...". استخدم الأذونات المحددة للمستأجر للأدوار الموجهة للعملاء.
• احتفظ بالأدوار مستقرة. تحديث أذونات الدور عندما تتغير الميزات---لا تعدل كل مستخدم.
• تدقيق بانتظام. مراجعة من لديه admin أو can_impersonate.

الأسئلة الشائعة

هل يمكن أن يكون لدى المستخدم أدوار متعددة؟ نعم. الأذونات تضاف.

هل أحتاج إلى أذونات مخصصة؟ عادة لا. يغطي الكتالوج المدمج معظم الاحتياجات.

كيف تعرف قواعد "رؤية الخاصة ..." ما هو لي؟ تقوم بتقييم الربط بين المستخدم/جهة الاتصال الخاصة بك وعميلك (المستأجر).