خطأ صلاحيات الرولز: `There is no permission named lis.critical-alerts.view`

تحليل كامل لنظام البيرمشن في الـLIS — المشكلة، السبب الجذري، ليه بيحصل، الإصلاح، والوقاية النهائية

التاريخ: 4 يونيو 2026 • الموديول: LIS / Core (Spatie Permissions) • الحالة: اتصلّح + اتأكد (HTTP 200)

1) المشكلة

عند تعديل أي رول من /lab/roles فيه صلاحية معيّنة، الحفظ بيفشل بـ500 والرسالة:

There is no permission named `lis.critical-alerts.view` for guard `web`.

ده استثناء من Spatie Permission — بيتحصل لما الكود يحاول يربط بالرول اسم صلاحية مش موجود في جدول permissions.

2) السبب الجذري (ليه بيحصل)

نظام البيرمشن فيه "موسّع تبعيات" (LisPermissionDependencies) بيضمن إن أي رول متماسك. وفيه قاعدة عامة:

// LisPermissionDependencies::dependenciesOf()
// أي lis.{res}.{action} غير الـview بيحتاج lis.{res}.view
if (count($parts) === 3 && $parts[2] !== 'view') {
    $deps[] = "lis.{$parts[1]}.view";   // ← بيضيف الـview تلقائياً
}

تختار في الرولlis.critical-alerts.acknowledge
(موجودة ✓)

←

التوسيع يضيفlis.critical-alerts.view
(القاعدة العامة)

←

syncPermissionsبيلاقي .view مش متزرّعة في الـDB

←

Spatie ترمي"There is no permission named…" → 500

🎯 الخلاصة

المورد critical-alerts اتزرّعت له صلاحية acknowledge بس من غير view. القاعدة العامة بتفترض إن كل مورد عنده view — والافتراض ده مكسور لـ5 موارد. أول ما رول يحتوي على واحدة من أفعالها، التوسيع بيضيف .view الغير موجودة → كراش.

3) الـAudit — كل الألغام (مش بس واحدة)

فحصت الـ155 صلاحية lis.* — لقيت 5 موارد ليها أفعال من غير .view، كل واحدة كانت هتعمل نفس الكراش:

المورد	الأفعال الموجودة	الناقص	الحالة دلوقتي
`lis.critical-alerts`	acknowledge	`view`	اتزرعت
`lis.insurance-invoices`	generate	`view`	اتزرعت
`lis.qc-results`	create, delete	`view`	اتزرعت
`lis.rejection-reasons`	manage	`view`	اتزرعت
`lis.result-reports`	generate, publish, view-history	`view`	اتزرعت

4) الإصلاح (اتعمل)

أ) إصلاح البيانات — زرع الـ5 views الناقصين

اتعملوا في الـDB الحيّة (firstOrCreate, guard=web) + اتضافوا لـRolePermissionSeeder.php عشان أي تنصيب جديد ياخدهم.

ب) إصلاح دفاعي — الـsync بقى آمن ضد أي فجوة مستقبلية

في LabRoleController::syncLisPermissions — بقى يفلتر القائمة الموسّعة على الصلاحيات الموجودة فعلاً قبل الـsync. فلو أي مورد جديد اتزرع غلط (من غير view)، الرول يتحفظ عادي بدل ما يعمل 500:

// قبل: بيرمي 500 لو فيه اسم مش موجود
$role->syncPermissions(array_merge($keep, $newLis));

// بعد: يفلتر على الموجود فعلاً
$existing = Permission::where('guard_name', 'web')
    ->whereIn('name', $wanted)->pluck('name')->all();
$role->syncPermissions($existing);   // مفيش كراش أبداً

✔ التأكيد

PUT /lis/roles/{id} بصلاحية lis.critical-alerts.acknowledge → HTTP 200، والـ.view اتضافت صح. الـaudit دلوقتي: 0 ألغام باقية.

5) الوقاية — عشان ميحصلش تاني

قاعدة ثابتة: أي مورد lis.{res} له أي فعل لازم يكون له lis.{res}.view في الـseeder. الـview هو "بوابة" المورد — مفيش مورد من غير view.
الـsync الدفاعي (اتعمل) — شبكة أمان: أي اسم صلاحية مش موجود بيتفلتر بدل ما يعمل كراش. ده بيحمي من أي فجوة seeder مستقبلية تلقائياً.
فحص اتساق (مقترح): أمر/تست بسيط بيتأكد إن لكل مورد عنده أفعال، عنده .view — يتشغّل في CI أو بعد أي تعديل على الـseeder، فالفجوة تتكشف قبل ما توصل للمستخدم:
```
// كل lis.{res} له فعل لازم له view
foreach (group(perms) as $res => $actions) {
   assert(in_array('view', $actions),
     "Resource lis.$res has actions but no .view");
}
```
عند إضافة مورد/شاشة جديدة: ضيف صلاحياته كـمجموعة كاملة (view + باقي الأفعال) دايماً، حتى لو الشاشة بتعمل فعل واحد بس.

6) الملفات المتأثرة

Modules/Core/database/seeders/RolePermissionSeeder.php — ضيف الـ5 views.
Modules/LIS/app/Http/Controllers/LabRoleController.php — الـsync الدفاعي.
Modules/LIS/app/Support/LisPermissionDependencies.php — مصدر القاعدة العامة (مفيش تعديل — هو الصح، بس بيفترض وجود الـview).

ملحوظة: ده غير guard مختلف — كل الصلاحيات على guard web (مفيش تعارض guards). المشكلة كانت بيرمشن ناقصة، مش guard غلط.