تحليل الفجوة — منظومة الصلاحيات (Permissions) في الـUI

١. المشكلة (كما وصفها المالك)

الواجهة بتعرض كل حاجة بغضّ النظر عن صلاحية المستخدم — مثال: زرار «إضافة طلب شراء» بيظهر لأي يوزر داخل على الشاشة، حتى لو المفروض عنده «عرض» بس.
حاسس إن مش كل المزايا ليها صلاحيات مسجّلة — ضرب مثال بموديول الإنتاج/التصنيع؛ محتاج المنظومة تتراجع كويس.

الهدف من التحليل: نفهم بالظبط ليه «كله بيظهر»، ونتأكد فين الصلاحيات فعلًا ناقصة، ونطلّع خطة إصلاح مرتّبة قبل أي كود.

٢. الوضع الحالي (ما هو موجود — بمراجع دقيقة)

البنية سليمة أساسًا

مصدر الصلاحيات: بتيجي على كائن المستخدم (roles[], permissions[]) من /auth/me واللوجين — core/models/auth.model.ts:39، وبتتخزّن في NgRx + localStorage، وPermissionService بيقرأها كـsignal.
صيغة الصلاحية: module.resource.action (مثال purchases.requests.create).
الكتالوج في الباك: مصفوفة واحدة فيها ١٠٠٠ صلاحية — RolePermissionSeeder.php::permissions() 210–1347، بتتزرع في جدول permissions (guard web)، وبتوصل العملاء عند التحديث عبر GrantRolePermissionsSeeder (إضافي، مبيشيلش).
تجاوز السوبر-أدمن: دور super-admin (أو مستخدم بأدوار+صلاحيات فاضية) بيعدّي كل الفحوصات — permission.service.ts:29 + Gate::before في الباك.

٣ طبقات تقييد موجودة في الفرونت

الطبقة	الملف	التغطية	الدقة
فلترة المنيو/الشريط	`sidebar.component.ts:138` · `module-nav.component.ts:240`	شبه كاملة (١١٩ عنصر)	بادئة `module.resource` (خشنة)
حارس الراوت `permissionGuard`	`auth.guard.ts:125`	٢٧٥ راوت مقيّد	بادئة (خشنة)
توجيه الزر `*appCan`	`can.directive.ts`	٦٧ ملف بس (مركّزة)	مطابقة تامّة (action)

الباك — التطبيق قوي ومتّسق

التقييد عبر Spatie permission: middleware على مستوى الـController (النمط السائد) أو الراوت (Clinic: ٢٠١/٢٠٦ راوت).
مفيش «صلاحية مطلوبة بس مش مسجّلة» في الـControllers المقيّدة — أي صلاحية بتتفحص موجودة في الكتالوج.
شاشة /core/roles بتنده GET core/permissions اللي بيرجّع كل الصلاحيات المسجّلة مجمّعة بالموديول — RoleController.php:191. فأي صلاحية مسجّلة بتظهر في المنتقي.

٣. المطلوب

الواجهة تقيّد المزايا فعليًا حسب صلاحيات المستخدم — يوزر «عرض» ميشوفش أزرار الإضافة/التعديل/الحذف/الاعتماد.
مراجعة اكتمال الكتالوج (خصوصًا الإنتاج) وسدّ أي مزايا مكشوفة بلا صلاحية.
ترتيب إدارة الأدوار (الوضوح والتكرار) عشان المالك يقدر يضبط «مين يشوف إيه» بسهولة.

٤. الفجوة (GAP) — الأدلة

أ) «الواجهة بتعرض كل حاجة» — مؤكَّدة ✅ (فرونت)

السبب المركّب: المنيو والراوتس بيقيّدوا على مستوى البادئة الخشنة (purchases.requests)، فيوزر معاه purchases.requests.view بيعدّي ويدخل الشاشة — وبعدين الأزرار مش متقيّدة بـ*appCan فبيشوف كل الحركات. + الاختبار بحساب سوبر-أدمن/أدمن بيتجاوز كل الفحوصات فبيخلّي المشكلة تبان «كلية».

الموديول	ملفات فيها `*appCan` / الإجمالي	الحالة
clinic	34 / 51	مقيّدة
production	14 / 49	جزئي
lis	17 / 101	جزئي
purchases	1 / 14 (مش requests)	شبه صفر
sales	0 / 16	صفر
hr	0 / 31	صفر
pos	0 / 17	صفر
inventory / accounting / core-admin (users, roles, products, partners, warehouses, journal-entries, accounts…)	0	صفر

دليل مباشر على شكوى المالك: purchases/requests/requests.component.html:6 — زرار «طلب جديد» <p-button (onClick)="openNew()"> من غير أي *appCan. نفس النمط في المبيعات/HR/POS/المخزون/المحاسبة.

ب) «الإنتاج ناقص صلاحيات» — الواقع مختلف (باك)

الإنتاج فعليًا أكثر موديول مقيّد في النظام: 44/44 Controller بيفرضوا صلاحيات، ٦٩ صلاحية مسجّلة، صفر endpoint مكشوف. فمش «ناقص تطبيق». لكن فيه ٣ أسباب ممكن تخلّي المالك يحسّها ناقصة 👇

صلاحيات خشنة (umbrellas): production.costing لوحدها بتغطّي الانحرافات + الأوفرهيد + التكلفة المعيارية؛ production.consume بتغطّي الـstaging + backflush + صرف المواد؛ production.reports.view بتغطّي ~٢٠ تقرير. فلو عايز فصل مهام أدقّ جوّه الإنتاج — الفجوة هنا «خشونة» مش «غياب».
١٢ دور خاص بالإنتاج مش بيوصلوا العملاء: ProductionRoleSeeder.php (production_cost_accountant, production_manager, …) مش مسجّل في seeders الـMoonStack — فالتثبيت/التحديث مبيجبهمش.
أسماء خام: منتقي الصلاحيات بيرجّع label == key (نص خام)، والفرونت بيترجم عبر ROLES.RESOURCES.*/ACTIONS.* — فأي resource/action في الإنتاج مالوش مفتاح ترجمة بيظهر خام/مبهم.

ج) الفجوة الحقيقية المكشوفة أمنيًا = LIS (مش الإنتاج) 🔴

مجموعة endpoints في LIS بلا أي صلاحية ولا middleware — أي مستخدم مسجّل يقدر يستدعيها: المضادات الحيوية (antibiotics CRUD)، الهيستوباثولوجي (النتائج + القوالب)، شركاء الباقات، تعيين باقات المعامل الخارجية — LIS/routes/api.php:489,605,785–810. ومفيش صلاحية lis.antibiotics.*/lis.histopath-templates.* أصلًا، فمش بتظهر في الشاشة وبتفضل مفتوحة.

د) عيوب وتناقضات

#	العيب	الأثر	مرجع
1	`*appCan` بنقطة أخيرة (`'clinic.payments.'`) — التوجيه بيستخدم `can()` مطابقة تامّة	الشاشة تختفي لكل غير-سوبر-أدمن (شغّالة بالغلط لأن الاختبار سوبر-أدمن)	`cashier-queue…html:1`
2	حارس الراوت يطابق بالبادئة → منح `resource.*` يفتح الشاشة كاملة	يهزم التقييد على مستوى الحركة	`auth.guard.ts:143`
3	٣ محرّرات أدوار (core / lis / clinic) + محرّري مستخدمين (core / lis) بـendpoints وكتالوجات مختلفة	تكرار وإرباك: «أضبط الصلاحية منين؟»	`features/{roles,lis/roles,clinic/roles}`
4	seeder ميت خطر `PermissionSeeder.php` بأسماء مفرد قديمة (`core.user.view`) وأدوار مكرّرة	لو اتشغّل بالغلط يلوّث الكتالوج (غير مُشار له حاليًا)	`PermissionSeeder.php:13`
5	٢ صلاحية إنتاج مُعرّفة وغير مفحوصة (`production.quality.inspect/disposition`) + ~٢٦ صلاحية يُحتمل ميتة + `inventory.products.` تكرّر `core.products.`	تنظيف كتالوج	تقرير الباك §4,§6

٥. الملفات المتأثرة والاعتماديات

فرونت (Angular)

shared/directives/can.directive.ts — إصلاح can()/البادئة
core/services/permission.service.ts — دالة فحص بادئة للأزرار لو لزم
أزرار كل شاشات: purchases/*, sales/*, hr/*, pos/*, inventory/*, accounting, core-admin (users/roles/branches/products/partners/warehouses/journal-entries/accounts)
features/roles/roles.component.ts — تحسين الترجمة/العرض
assets/i18n/{ar,en}.json — مفاتيح ROLES.RESOURCES.*/ACTIONS.* الناقصة (إنتاج وغيره)
app.routes.ts / lis-standalone.routes.ts — تكرار تسجيل lis/roles

باك (Laravel/Spatie)

LIS/routes/api.php + LabNewTypesController, LabHistopathTemplateController, LabPackagePartnerController, LabExternalLabPackageController — إضافة صلاحيات + middleware
Core/database/seeders/RolePermissionSeeder.php — صلاحيات LIS الجديدة + (اختياري) تقسيم umbrellas الإنتاج
config/moonstack.php — تسجيل ProductionRoleSeeder في seeders التحديث
Core/database/seeders/PermissionSeeder.php — حذف (ميت)

٦. الحالات الحدّية

سوبر-أدمن / أدمن المالك: بيشوفوا كل حاجة بالتصميم — لازم الاختبار بيوزر بصلاحيات محدودة، مش بالأدمن (وإلا الإصلاح مش هيبان).
«عرض» مقابل «حركة»: الهدف إن يوزر معاه .view يدخل الشاشة لكن أزرار .create/.update/.delete/.approve تختفي.
عدم تطابق النصوص: أي *appCan بسلسلة غلط بيخفي الزر بصمت — لازم تطابق كتالوج الباك بالحرف (فحص آلي مقترح).
حُرّاس البوابات المنفصلة (متجر WebStore، بوابات المرضى/المعامل الخارجية) خارج كتالوج الأدمن — مايتلمسوش.
وصول الصلاحيات الجديدة للعملاء: أي صلاحية جديدة لازم تدخل RolePermissionSeeder عشان تتزرع عند التحديث (وإلا مش هتظهر ولا تتفرض).
RTL/i18n: مفاتيح الترجمة للـresources/actions لازم تتغطّى عربي/إنجليزي.

٧. خطة التنفيذ (Work Packages بالترتيب)

P0 تقييد الأزرار في الواجهة (شكوى المالك #1). إضافة *appCan على كل أزرار الإضافة/التعديل/الحذف/الاعتماد في الموديولات غير المغطّاة (المشتريات، المبيعات، HR، POS، المخزون، المحاسبة، إدارة-Core)، بسلاسل مطابقة لكتالوج الباك بالحرف. + إصلاح مشكلة النقطة الأخيرة (استخدام فحص بادئة للأزرار prefix بدل can() التامّة، أو تصحيح السلاسل). ملفات: أعلاه · اختبار: build أخضر + فحص يدوي بيوزر «عرض».

P0 سدّ endpoints المكشوفة في LIS. إضافة صلاحيات (lis.antibiotics.*, lis.histopath.*, lis.histopath-templates.*, lis.packages.partners.*, lis.external-labs.packages.*) لكتالوج الباك + permission: middleware على الكونترولرات الأربعة. [أمني — أولوية].

P1 وضوح شاشة الأدوار + الترجمة. استكمال مفاتيح ROLES.RESOURCES.*/ACTIONS.* لكل الموديولات (الإنتاج أولًا) عشان الصلاحيات تظهر بأسماء عربية واضحة بدل النص الخام.

P1 إيصال أدوار الإنتاج للعملاء. تسجيل ProductionRoleSeeder في seeders تحديث MoonStack (إضافي، غير هدّام) — فالـ١٢ دور توصل التثبيتات.

P2 توحيد محرّرات الأدوار/المستخدمين (قرار مالك — قسم ٨): دمج core/lis/clinic في مدخل واحد، أو الإبقاء على «قشرة» لكل موديول مع توضيح.

P2 تنظيف الكتالوج. حذف PermissionSeeder.php الميت · مراجعة الـ٢٦ صلاحية المشكوك فيها · حسم inventory.products.* المكرّرة · حسم/ربط صلاحيتَي الجودة المعطّلتين.

P3 (اختياري) تشديد حُرّاس الراوت أو تقسيم umbrellas الإنتاج لفصل مهام أدقّ — حسب قرار المالك.

٨. قرارات تحتاج المالك (مع توصية)

القرار	الخيارات	التوصية
مستوى تقييد الواجهة	(أ) إخفاء أزرار الحركة ليوزر العرض [الأساسي] · (ب) + تشديد الراوت لمستوى الحركة كمان	ابدأ بـ(أ) — بتحلّ الشكوى بأقل خطر؛ (ب) لاحقًا لو محتاج منع الوصول للصفحة نفسها.
محرّرات الأدوار (٣)	(أ) توحيد في `/core/roles` واحد · (ب) إبقاء قشرة lis/clinic مع توضيح النطاق	(أ) الأنظف للمالك — مدخل واحد لكل الصلاحيات.
خشونة صلاحيات الإنتاج	(أ) سيبها umbrellas · (ب) قسّم (variances/standard-costs/consume منفصلة)	(أ) الآن — التقسيم مشروع منفصل لو الحوكمة طلبته.
أدوار الإنتاج للعملاء	(أ) شحنها للأسطول · (ب) سيبها يدوية	(أ) — قيمة مباشرة، إضافية وآمنة.

٩. معاينة الواجهة المتوقّعة (WP1 — بيمسّ الـUI)

التغيير الأساسي «غير مرئي»: نفس الشاشات، لكن أزرار الحركة تختفي لمن مالوش صلاحيتها. مثال — شاشة طلبات الشراء ليوزر معاه purchases.requests.view فقط:

قبل (الحالي) — كل الأزرار ظاهرة ❌

طلبات الشراء+ طلب جديد

الرقم	المورّد	الحالة	إجراءات
PR-0007	مورّد أ	مسودة	تعديلحذفاعتماد

بعد (المتوقّع) — أزرار الحركة مخفية ✅

طلبات الشراء+ طلب جديد

الرقم	المورّد	الحالة	إجراءات
PR-0007	مورّد أ	مسودة	تعديلحذفاعتمادعرض فقط

التطبيق: *appCan="'purchases.requests.create'" على «طلب جديد»، و.update/.delete/.approve على أزرار الصف. نفس النمط يتكرّر على كل الشاشات غير المغطّاة. شاشة /core/roles نفسها كويسة ومش محتاجة إعادة تصميم — بس ترجمة أوضح (WP3).

تحليل قراءة-فقط · فحص Opus لـ BE+FE · مراجع دقيقة من تقريرَي الوكيلين · لم تُعدَّل أي بيانات أو كود. بانتظار موافقة المالك قبل أي تنفيذ.