التفويض

يحدد التفويض ما يمكن للمستخدمين فعله وما لا يمكنهم فعله بعد المصادقة. يجمع Aptli بين طبقتين مستقلتين: حقوق الإدارة المتساهلة (ما يمكنك فعله) وقيود الأدوار التقييدية (ما لا يمكنك رؤيته). وتمنح هاتان الطبقتان معًا المسؤولين تحكمًا دقيقًا في كل من القدرات وإمكانية رؤية البيانات.

نظرة عامة على نموذج التفويض

يتكون نموذج الأمان الكامل لـ Aptli من ثلاث طبقات:

1. المصادقة — من أنت (تمت تغطيتها في قسم المصادقة)
2. حقوق الإدارة — ما يمكنك تعديله (الامتيازات المسموح بها)
3. قيود الأدوار — ما لا يمكنك رؤيته (مرشحات تقييدية)

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

يوفر هذا النموذج مرونة هائلة مع الحفاظ على الأمان.

حقوق الإدارة (تساهلية)

تمنح حقوق الإدارة الإذن بتعديل المعلومات أو تغيير الحالة. بدون هذه الحقوق، يمكن للمستخدمين فقط عرض البيانات وتحرير ملفهم الشخصي.

حقوق الإدارة عبارة عن مجموعة قابلة للتخصيص حسب كل مستخدم (user.admin). كل إدخال يمثل اسم حق واحد؛ ولا يتم تجميعها في حزم. تُمنح الحقوق مباشرةً للمستخدم، ولا تُورث أبدًا من دور ما.

حقوق الإدارة الشائعة:

• usersUpdate - تعديل ملفات تعريف المستخدمين الآخرين (الاسم، اللقب، القسم - وليس البريد الإلكتروني/كلمة المرور)
• usersLogout - فرض تسجيل الخروج أو قفل حسابات المستخدمين بشكل نهائي
• usersDelete - حذف حسابات المستخدمين
• usersCreate - إنشاء مستخدمين جدد أو استعادة الحسابات المحذوفة
• featureCreate، featureUpdate، featureDelete - تعديل ميزات الخريطة (النقاط، الخطوط، المضلعات)
• allowCommits - نشر إصدارات الخريطة مباشرةً (وإلا فإن زر «إرسال» يُعتبر طلبًا لمراجعة المسؤول)
• jobsCreate، jobsUpdate، jobsDelete - إدارة المهام (وحدات العمل المخطط لها)
• workOrdersCreate، workOrdersUpdate، workOrdersDelete - إدارة أوامر العمل
• reportsCreate، reportsUpdate، reportsDelete - إرسال تقارير العمل وإدارتها
• validationsCreate، validationsUpdate، validationsDelete - الموافقة النهائية من قسم ضمان الجودة على التقارير
• activitiesCreate، activitiesUpdate، activitiesDelete - صيانة كتالوج الأنشطة (أنواع العمل)
• projectsCreate، projectsUpdate، projectsDelete - إدارة المشاريع
• transactionsCreate - إنشاء معاملات المخزون (دفتر الأستاذ مخصص للإدراج فقط — لا توجد صلاحية للتحديث أو الحذف)
• canFacilitatePickups - توزيع المواد إلى شخص ما عبر استلام برمز الاستجابة السريعة (QR) نيابة عنه
• canTransferStock - نقل المخزون بين المواقع (المواقع هي عمليات النقل، والأشخاص هم المستلمون)

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

الحقوق الفائقة (تتجاوز جميع الحقوق الأخرى):

• appSettingSchemasModify - تعديل الإعدادات على مستوى التطبيق (المجالات، فترات الانتظار، الأمان)
• adminRightsModify - منح حقوق الإدارة لمستخدمين آخرين
• viewDeleted - عرض السجلات المحذوفة (شبه شامل، يتم تجاوزه جزئيًا بواسطة قيود الأدوار)

التحقق من حقوق الإدارة للمستخدم:

1. انتقل إلى «الإدارة» → «المستخدمون»
2. افتح ملف تعريف المستخدم
3. يسرد قسم «حقوق الإدارة» جميع الأذونات الممنوحة

قيود الأدوار (تقييدية)

الأدوار هي مجموعات من القيود التي تمنع عرض وتعديل السجلات ذات الخصائص المحددة. لا يحتوي الدور سوى على اسم وقائمة بالقيود — ولا شيء غير ذلك. لا تتضمن الأدوار أعضاءً أو مالكًا أو حقوق إدارية. تتعلق العضوية بالمستخدم: لكل مستخدم قائمة «الأدوار»، ويتم تطبيق كل قيد من تلك الأدوار على ذلك المستخدم.

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

مكونات الدور:

• الاسم - تسمية يمكن قراءتها بسهولة
• قيود الدور - عوامل تصفية على مستوى الحقول تخفي بيانات محددة

تقتصر الأدوار على تحديد نطاق الرؤية والقيود فقط. فهي لا تمنح أبدًا القدرة على القيام بأي شيء — فهذا هو الغرض من حقوق الإدارة.

هيكل قيود الدور

يحدد كل قيد ما يلي:

• النموذج (target_model) - نوع البيانات (المستخدم، الميزة، الدور، إلخ)
• الحقل - الخاصية التي سيتم التصفية بناءً عليها (المالك، الحالة، الفئة، الحقول المخصصة)
• المقارنة - كيفية المطابقة. أحد الخيارات التالية: eq، ne، gt، gte، lt، lte، in، nin
• قيمة التصفية - القيمة التي سيتم المقارنة معها (قيمة واحدة، أو مصفوفة في حالة in/nin)
• الأذونات - مصفوفة من العمليات التي يتم رفضها عند مطابقة السجل. كل إدخال هو أحد الخيارات التالية: read، edit، create، delete. إدراج عملية هنا يؤدي إلى حظرها؛ أما تركها خارج القائمة فيسمح بها.

تعرض واجهة المستخدم الخاصة بإدارة الأدوار هذه العناصر كأعمدة «النموذج» / «الإجراء» / «المسار».

مثال على حالة الاستخدام: الفصل بين المقاولين

السيناريو: منع المقاول «أ» من رؤية عمل المقاول «ب»

الإعداد:

1. إنشاء دور: «المقاول أ»
2. إضافة تقييد للدور:
   • النموذج: الميزة
   • الحقل: المالك
   • المقارنة: يساوي
   • قيمة التصفية: المقاول ب
   • الأذونات (ممنوعة): القراءة، والتحرير، والإنشاء، والحذف (تم حظر الأربعة جميعًا)
3. إضافة دور «المقاول أ» إلى مستخدمي المقاول أ (من ملف تعريف كل مستخدم)

النتيجة:

• لا يمكن لأعضاء المقاول أ رؤية أي ميزات يكون فيها المالك = «المقاول ب»
• لا يقتصر الأمر على إخفائها في واجهة المستخدم فحسب — بل تُرجع واجهة برمجة التطبيقات (API) البيانات كما لو أن السجلات غير موجودة
• لا يمكن رؤيتها عن طريق الخطأ عبر لقطة شاشة أو استدعاء واجهة برمجة التطبيقات (API) أو التصدير
• يتم فرضها بالكامل من جانب الخادم

حالات استخدام إضافية

حسب مرحلة العمل: منع العاملين الميدانيين من رؤية تقارير التحقق من الجودة:

Role: "Field Workers"
Restriction:
  Model: validation
  Field: status
  Comparison: ne
  Filter Value: "" (any value)
  Permissions (denied): read

لا يمكن للعاملين الميدانيين رؤية عمليات التحقق على الإطلاق.

حسب نوع الأصول: فصل فرق البنية التحتية (الأعمدة/القنوات مقابل المعدات النشطة):

Role: "Civil Team"
Restriction:
  Model: feature
  Field: category
  Comparison: eq
  Filter Value: "Active Equipment"
  Permissions (denied): read, edit, create, delete

لا يمكن لفريق الهندسة المدنية رؤية أو تعديل ميزات المعدات النشطة.

حسب المادية/المنطقية: وصول منفصل إلى بيانات المكاتب (علاقات السعة مقابل مواقع المكاتب):

Role: "Capacity Analysts"
Restriction:
  Model: feature
  Field: layer
  Comparison: eq
  Filter Value: "Office Locations"
  Permissions (denied): edit, create, delete

يمكن للمحللين عرض المكاتب ولكن لا يمكنهم تعديل المواقع (للقراءة فقط — القراءة غير مرفوضة).

الجمع بين حقوق المسؤول + قيود الدور

السلوك الافتراضي: يمكن لجميع المستخدمين رؤية كل شيء ولكن لا يمكنهم تغيير أي شيء (بدون حقوق المسؤول).

إضافة حق الوصول للكتابة مع قيود:

مثال: يمكن للعاملين الميدانيين تعديل أعمالهم الخاصة ولكن لا يمكنهم تعديل أعمال الآخرين

Admin Rights:
  - reportsCreate: true
  - reportsUpdate: true

Role Restrictions:
  Model: report
  Field: submittedBy
  Comparison: ne
  Filter Value: [current user ID]
  Permissions (denied): edit

النتيجة:

• يمكن للعاملين إنشاء تقارير (حقوق المسؤول ممنوحة)
• يمكن للعاملين تعديل تقاريرهم الخاصة فقط (قيود الدور تستبعد تقارير الآخرين)
• لا يمكنهم رؤية أو تعديل تقارير العاملين الآخرين

التنفيذ من جانب الخادم

كيفية العمل:

• يتم تصفية جميع الاستعلامات قبل إرجاع البيانات
• تُطبق قيود الدور على الخادم (وليس مجرد إخفاء في واجهة المستخدم)
• لا يمكن للمستخدمين التحايل عبر استدعاءات API المباشرة أو أدوات المتصفح أو عمليات التصدير
• البيانات غير موجودة فعليًا بالنسبة للمستخدمين غير المصرح لهم

الآثار الأمنية:

• لن تفيدك لقطة شاشة لشاشة شخص آخر (لن يتم تحميل البيانات لك)
• لا يمكن تصدير البيانات المقيدة (يقوم الخادم بفرض المرشحات)
• لا يمكن «تخمين» معرّفات السجلات (يتم ترشيحها قبل البحث عن المعرّف)
• تظهر السجلات التي تقع خارج نطاق أذوناتك على أنها «غير موجودة»، حتى لو كنت تعرف المعرّف

إدارة الأدوار

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

1. انتقل إلى «الإدارة» → «الأدوار»
2. انقر على «إنشاء دور»
3. أدخل اسم الدور
4. أضف قيود الدور (يمكن أن يكون هناك أكثر من قيد)
5. احفظ

يتطلب إنشاء دور حق الإدارة rolesCreate.

تحرير الأدوار:

• يتطلب حق الإدارة rolesUpdate
• يمكن تعديل القيود
• يمكن حذف الدور باستخدام rolesDelete (يحرر الأعضاء من تلك القيود)

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

عضوية الدور:

• العضوية مرتبطة بالمستخدم (user.roles)؛ أضف الأدوار أو أزلها من ملف تعريف المستخدم
• يمكن للمستخدمين أن يكونوا في أدوار متعددة (يتم دمج القيود)
• مغادرة المؤسسة: أزل جميع الأدوار من المستخدم قبل حذف الحساب

تخصيص التفويض للمستخدمين الجدد

تكوين إعدادات التطبيق (يتطلب appSettingSchemasModify):

1. انتقل إلى «إعدادات التطبيق»
2. «الأدوار الافتراضية» — الأدوار التي يتم تعيينها تلقائيًا للحسابات الجديدة
3. حفظ

لا يوجد إعداد «حقوق إدارية افتراضية» — يبدأ المستخدمون الجدد دون أي حقوق إدارية. قم بمنح الحقوق لكل مستخدم من ملفه الشخصي بعد إنشاء الحساب.

التكوينات النموذجية:

العامل الميداني:

• الأدوار الافتراضية: ["Field Workers"]
• حقوق الإدارة الممنوحة للمستخدم بعد الإنشاء: reportsCreate

منسق المكتب:

• الأدوار الافتراضية: لا شيء
• حقوق الإدارة الممنوحة للمستخدم بعد الإنشاء: workOrdersCreate، stockItemsCreate، stockItemsUpdate

لا يوجد منح تلقائي (مراجعة يدوية):

• الأدوار الافتراضية: لا شيء
• يقوم المسؤولون بتعيين الأدوار والصلاحيات يدويًّا بعد مراجعة الحساب.

عرض الصلاحيات السارية

لمستخدم معين:

1. انتقل إلى ملف تعريف المستخدم
2. قسم «حقوق المسؤول» - ما يمكنه فعله
3. قسم «الأدوار» - ما لا يمكنه رؤيته (عبر القيود)
4. يعرض العرض المدمج الأذونات السارية

اختبار الأذونات:

1. قم بتسجيل الدخول كمستخدم (أو انتحل شخصيته باستخدام أذونات المسؤول)
2. تصفح الموقع بشكل عادي
3. البيانات المقيدة ببساطة لا تظهر
4. الإجراءات التي تتطلب صلاحيات إدارية تكون معطلة/مخفية

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

ابدأ بالتقييد، ومنح الصلاحيات حسب الحاجة:

• يحصل المستخدمون الجدد على الحد الأدنى من الصلاحيات
• أضف صلاحيات إدارية حسب متطلبات الأدوار
• منح الأذونات أسهل من سحبها (يتجنب «توسع الأذونات» غير المقصود)

استخدام الأدوار لتحديد رؤية البيانات:

• فصل المقاولين (لمنع الحصول على معلومات تنافسية)
• فصل مراحل العمل (فصل مراقبة الجودة عن العاملين الميدانيين)
• فصل أنواع الأصول (فصل البنية التحتية عن المعدات العاملة)

استخدام صلاحيات الإدارة لتحديد القدرات:

• من يمكنه إنشاء المهام
• من يمكنه تعديل المخزون
• من يمكنه منح الأذونات

توثيق الغرض من الدور:

• اسم دور واضح («المقاول أ» أفضل من «الدور 1»)
• الوصف يوضح القيود
• يساعد المسؤولين المستقبليين على فهم المقصد

عمليات تدقيق منتظمة للأذونات:

• مراجعة حقوق الإدارة الخاصة بالمستخدمين كل ثلاثة أشهر
• إزالة الحقوق غير المستخدمة (تغيير أدوار المستخدمين)
• التحقق من عضوية الأدوار (المستخدمون الذين غادروا المؤسسة)

مراقبة محاولات الوصول:

• تسجيل محاولات المصادقة الفاشلة
• نمط الرفض = محاولة المستخدم الوصول غير المصرح به
• التحقيق وتعديل الأذونات أو توعية المستخدم

مبدأ الحد الأدنى من الامتيازات:

• منح الحد الأدنى من الأذونات المطلوبة لأداء المهام الوظيفية
• منح وصول مؤقت بامتيازات أعلى للمشاريع (إزالته بعد انتهاء المشروع)
• منح الصلاحيات الفائقة (adminRightsModify) للمسؤولين الموثوق بهم فقط